Sprint Planning

Sprint Planning opens each Sprint, and the resulting plan gets created through collaboration with the entire Scrum Team. The Product Owner will discuss the Sprint Goal with their Scrum Team. Then, they'll work together to reach a shared understanding of the Sprint Goal in addition to the work to be done to achieve it.

The team then estimates any Product Backlog Items (PBIs) that haven't been estimated already or emerged during the Sprint Planning session. The Team may need to break large PBIs down into smaller, more manageable pieces of work. The team pulls from the top of the now ready Product Backlog based on the amount of work the team can commit to completing in the Sprint. The best practice to gauge how much work can be done in a Sprint is to use the Yesterday's Weather pattern by only pulling the amount of work completed in the previous Sprint. Team capacity, which almost always varies week-to-week, also needs to be taken into account. (Jeff explains this process in the video).

In short, Sprint Planning addresses the following three topics:

1) Why is this Sprint valuable?
2) What can be accomplished this Sprint?
3) How will the chosen work get done?

The team needs to commit to how much work can be done in the next Sprint. They should not feel pressured by anyone outside their team to do more. If a Scrum Team is not confident that they can deliver the Sprint Backlog a negotiation with the Product Owner should take place. One of Scrum's core ideas is that only the people who will do the work know how much effort it will take.

Like all Scrum ceremonies, the Sprint Planning meeting is time-boxed. It should take no longer than two hours per week of Sprint length. Regular and effective Backlog Refinement will dramatically reduce the time spent in Sprint Planning.