Use the Sprint Planning Canvas as a template to help you and your team run effective Sprint Planning events.
The Scrum Guide defines Sprint Planning as the event that initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Sprint starts with Sprint Planning. The input to the Sprint is the Product Backlog and the team’s historical performance as well as the team’s current capacity. The output of the Sprint is the Sprint Backlog which is the team’s plan to accomplish the work.
Sprint Goal – The Why
The Product Owner kicks off Sprint Planning by discussing the goal for the Sprint. Why is this Sprint important? How does this Sprint map to the Product Goal? The Product Owner proposes how the Product Increment resulting from this Sprint will get the team and product one step closer to the overall Product Goal. Next, the entire team collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders and users. There should be a direct connection between the Sprint Goal, the Product Goal, the product roadmap, and the overall vision.
The Product Backlog Items – The What
Next, the Developers and Product Owner collaborate to select a cohesive set of high priority “Ready” Product Backlog Items that are needed to produce the Product Increment and deliver on the Sprint Goal. The Developers consider their historical performance to determine how many items to discuss. The Developers and Product Owner go through each Product Backlog Item and clarify any remaining questions, finalize the acceptance criteria, and review the high-level estimates. There should be no surprises in Sprint Planning. The items being discussed are items that have already gone through Product Backlog Refinement. The user stories have gone through multiple refinement sessions as they moved up the Product Backlog. They were progressively elaborated on, clarified, and broken down into small valuable vertical slices of end-to-end functionality, and properly sized to fit in the Sprint.
The Tasks – The How
Next, Developers determine the activities that are needed to achieve the goal. For each Product Backlog Item, Developers task out the work needed to complete the PBI and create and deliver the Product Increment. Developers ask for additional clarifications if needed. Developers estimate the tasks, keeping in mind the team’s Definition of Done. Developers also consider any additional tasks that came out from the Retrospective as well as tasks for spikes that came out from Product Backlog Refinement.
Finally, Developers review their capacity and assess if they have high confidence that they will complete the tasks and deliver on the Sprint goal. If they determine that they have taken on too much, they inform the Product Owner and negotiate what to leave out.
The Sprint Planning ends with the Scrum team making a commitment to each other to accomplish the Sprint Goal. The Sprint Backlog is created consisting of the Sprint Goal, the cohesive set of Product Backlog Items, and the breakout of the tasks and activities needed to accomplish the goal.