What is sprint planning about?

There is a good discussion forming on the VersionOne google group about sprint planning. As people were starting to weigh in, I found myself writing more than a forum response... so here's my blog post about it. On my last review, I cut chunks out of this to shorten it... so there is much more to say on this subject.

The following is a description based on my last environment since it was a more mature agile team. We always treated sprint planning as a time-boxed event.
_________

A major goal of sprint planning is to make a commitment to what is intended to be delivered by the end of the sprint.

To do this, you:

• need customer/team input on what items from prior sprints need revisiting before moving forward (incomplete stories)
• need product owner/customer input on what is important to tackle next
• need estimates on these items to understand relative size (unless everything is sized the same)
  
• need an understanding of team velocity

Sometimes sprint planning will already have all these things completed (may happen throughout the sprint and during review), but if not, this should be the first focus during sprint planning.

• First bullet, assess the realities of where you are. There might be items that were rejected during sprint review for whatever reason that now need follow-up work before being marked as DONE. Also, a mature team might have a few stories started for the next sprint because they've learned how to keep their cadence and view sprint boundaries as a point of measurement instead of a true work-stop.
  
• Second bullet, have a prioritized backlog. It might shift throughout the sprint due to changing conditions from the market, the feedback from the users, or the complexities uncovered while building the software. This needs to be reviewed and updated so the team understands what is near the top of the list.
• Third bullet, perform just in time design. As items were put on the backlog, enough design should have been done to estimate them in comparison to each other and properly size them. Now the design should be discussed further to insure that anyone on the team has an idea how they would tackle the work and could see themselves taking it on (but leave the black-box details to the folks doing the work during the sprint). If you have specialized resources, then it might be possible that only those resources need to be involved in that conversation (not my personal preference).
• Fourth bullet, how much does the team normally get done? This is your velocity.
  

In an immature agile team (or one with current difficulties) this may be as far as you get during a time-boxed sprint planning session. The agile coach or scrum master can guide everyone on how it will go forward from there. Slice of the top an amount of work matching your velocity and go!

Of course this isn't optimal. So, if you were well-prepared and still have time after answering these questions... then what?

The team reviews the backlog and makes a selection of work they will target for the sprint. They should take into account things like removing risk earlier, not stumbling over each other in the code, the knowledge they have on the team, specialized resource bottlenecks, etc. This may lead the team to negotiate with the customer or product owner to skip over something at the top of the backlog for now.

This is the optimal minimum point to get to for sprint planning. A list of backlog items (stories) that the team has committed to tackling that is also acceptable to the customer / product owner. This is a set list that can be statused, monitored, and managed throughout the sprint. Because the team committed to it, there is a level of accountability that people will take responsibility for.

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. Explicitly this is a selection. Implicitly, this is the top group of stories that add up to their prior sprint's velocity.