Sprint Planning

[Jenny]

Can you all give me an idea of how your Sprint Planning meetings go?
Specifically, are you breaking down tasks/tests in this meeting for
those Backlog/Defect items that have been chosen for the
Sprint..or...are you not going to this level of detail in this meeting
and conducting other smaller informal discussions for these detail
breakdowns.

Thanks!

[Lee Cunningham]

We break the backlog items down into tasks and don't leave the meeting until every task has has an owner (via self-selection).  The understanding is that this is the best breakdown we can generate based on what we know right now.  Continuous team interaction and the daily standups provide indications that tasks may need to be added/deleted/reestimated, or if some load balancing of tasks among team members needs to take place.

[Jeff Pek]

Just curious: are you all in one location? How long does this typically take you?

Is anyone trying this approach with a distributed team?

 

We’ve taken to having people prepare for the sprint kickoff by tasking out stories on their own (or in small groups), and then using the kickoff to present each story with its estimate. This worked pretty well, but I know goes against the Scrum “rules”.

 

Thanks,

  Jeff

[Lee Cunningham]

Most of the team is in one location, but we have two who have to dial in from other time zones.  For a team of  7 and a 3-week sprint, it usually takes us about 3-4 hours.  What helps is that we allocate about half of one team member's capacity every sprint to work with the product owner to "groom" the top priority items in the release backlog. So in the sprint planning meeting, for each item, pulling from the top, the product owner gives the functional low-down, then the team member who helped do the grooming relays any technical information that he/she deems relevant, then the team discusses and tasks it out, then somebody signs up for each task.  The lack of the need to be "right", and the expectation that things will change, makes people feel comfortable working like this.

[komaya]

We normally have pre-planning meeting to set product backlog priorities and come to the planning meeting with a list of high priority stories.  We then do our story points to determine a rough estimate of what we can commit to.  Once that's done, we task out each story and detailed estimate in hours.  The planning can take 3-6 hours base on the number of stories and their complexity.

[Kevin S.]

All of the responses here are good ones, even if they don't follow the
"rules". It's more important we achieve the intention of sprint
planning and less important how we get there.

I just put up a blog post on sprint planning and how it has worked for
me:
http://agile-commentary.blogspot.com/2008/11/what-is-sprint-planning-about.html
I didn't want to put all that content here, but here is the snippet to
answer Jenny's specific question:

"... If you still have time in sprint planning, I've seen some groups
break down the stories into tasks. If the team is mature, they can do
this without knowing/caring who will do the work later (including task
estimates). If not, then they might want to wait until someone picks
the story up themselves. In really immature teams (technical
immaturity, not necessarily agile), the architect or senior members
may lay out the task work and estimates as a guide for the junior team
members when they get to it. At this point, there's a lot of variance
based on the team's needs, culture, skill sets, agile maturity, etc.

The bare minimum is that the team walks out of sprint planning with a
commitment for sprint delivery that they can hold themselves
accountable to... "

On Nov 7, 1:54 pm, komaya <kom...@gmail.com> wrote:
> We normally have pre-planning meeting to set product backlog priorities and
> come to the planning meeting with a list of high priority stories.  We then
> do our story points to determine a rough estimate of what we can commit to.
> Once that's done, we task out each story and detailed estimate in hours.
> The planning can take 3-6 hours base on the number of stories and their
> complexity.
>

> On Fri, Nov 7, 2008 at 10:49 AM, Jeff Pek <jeff....@autodesk.com> wrote:
> >  Just curious: are you all in one location? How long does this typically
> > take you?
>
> > Is anyone trying this approach with a distributed team?
>
> > We've taken to having people prepare for the sprint kickoff by tasking out
> > stories on their own (or in small groups), and then using the kickoff to
> > present each story with its estimate. This worked pretty well, but I know
> > goes against the Scrum "rules".
>
> > Thanks,
>
> >   Jeff
>

> > *From:* versiono...@googlegroups.com [mailto:
> > versiono...@googlegroups.com] *On Behalf Of *Lee Cunningham
> > *Sent:* Friday, November 07, 2008 1:32 PM
> > *To:* versiono...@googlegroups.com
> > *Subject:* Re: Sprint Planning

>
> > We break the backlog items down into tasks and don't leave the meeting
> > until every task has has an owner (via self-selection).  The understanding
> > is that this is the best breakdown we can generate based on what we know
> > right now.  Continuous team interaction and the daily standups provide
> > indications that tasks may need to be added/deleted/reestimated, or if some
> > load balancing of tasks among team members needs to take place.
>

> > On Thu, Nov 6, 2008 at 1:25 PM, Jenny <jennifer.shel...@torrentcorp.com>