> On 5/25/12 7:12 PM, dotnetguy wrote:

> > In Sprint Retrospectives, the team discusses what went well and what
> > needs improvement.  How do you normally handle the items that team
> > members recommend for improvement?

> > One could argue that small issues should be discussed and resolved in
> > the retrospective while more complex issues should be noted but
> > deferred for deeper discussion.

> > My first impression is that *all* attempted issue resolution should be
> > *deferred* so the meeting can focus solely on identifying and
> > clarifying issues that need to be resolved.  Otherwise, some issues
> > could be perceived as small by a subset of the team and these issues
> > may not be treated with the actual amount of attention required.  This
> > would also help keep the team focused on the task at hand.

> > So my perspective is that the goal of a Sprint retrospective should be
> > solely to *identify* issues *not* to resolve issues.  The process of
> > addressing the issues should come later.  I'm not sure if Scrum has an
> > official stance on this.  What's your opinion?

> It's not clear to me what sort of issues can be resolved during the
> retrospective. Nor why the team is making recommendations rather than
> choosing actions that they can accomplish.

> It would help me if you would describe what retrospectives mean to you,
> and give some examples of the issues the team identifies to resolve.
> Much of the Scrum literature is pretty weak on the topic of
> retrospectives, and I've seen a wide variety of ceremonies given that name.

>   - George

> --
>   ----------------------------------------------------------------------
>    * George Dinwiddie *                      http://blog.gdinwiddie.com
>    Software Development                    http://www.idiacomputing.com
>    Consultant and Coach                    http://www.agilemaryland.org
>   ----------------------------------------------------------------------