Sprint planning is a Scrum event that takes place right at the beginning of each sprint. The whole Scrum team attends, and the objective is to determine the following:
- What should we build before the end of the sprint?
- How shall we build it?
Before the start of the sprint, it is useful to prepare the following information and have it ready for sprint planning:
- Product backlog: The product owner brings along an ordered list of requirements. Items near the top of the list have been well analysed and are clearly understood.
- Definition of Done: The quality standards of the product have been defined, so that the team are aware of any additional tasks that they may need to plan in.
- Capacity: Any information that might help the team to forecast the amount of work they can take on, such as velocity and team availability.
During the meeting
The recommended flow of events for the sprint planning meeting is as follows:
- What? The product owner takes the first requirement from the top of the product backlog and explains it to the rest of the team. There is time for questions and discussion on how this requirement should be implemented. Most of the big decisions have been made in previous product backlog refinement sessions, and everyone should be relatively familiar with the work at hand. This is a final check point to confirm what should be built.
- How? The development team create a detailed technical plan to implement the feature based on the established requirements. This will often involve breaking a requirement down into sub-tasks and perhaps estimating these sub-tasks in hours.
- Are we done? Having created a plan for the first requirement, the development team look at their capacity and confirm whether they believe they can complete the feature within the sprint. If so, it is added to the sprint backlog. If there is still room for more work, the cycle is continued from step 1 until the team decide they have reached their capacity.
Outcomes and sprint goals
At the end of the session, the key outcome is a plan for the sprint articulated in a sprint backlog. This represents the development team’s forecast for what they believe they can deliver. This is sometimes supplemented with a sprint goal – a high level objective that is understood to be the key outcome for the sprint. This is useful for the team to establish a strong sense of purpose, and to guide them if things go off track. For example, if there are delays due to technical issues, unplanned bug fixes, or other impediments, the original forecast may not be achievable. In this event, the team may ask themselves whether it is possible to adjust the scope of the sprint but still meet the sprint goal.
Sprint planning factsheet
To download our Sprint planning factsheet, visit our agile factsheets page.