A sprint planning meeting is conducted before the start of a sprint. A sprint is an iterative element in the development process and is usually for a period of 1 - 4 weeks, with 2 weeks being the most common duration The purpose of this meeting is to determine the sprint plan, commit to it and set a sprint goal. This meeting is split into two sessions.
1. What can be done in this sprint? In the first session, the product owner reviews the list of features and explains the highest priority requirements to the team. He defines what needs to be built during the next sprint. The team and the product owner collaborate and define the sprint goal.
2. How will the chosen work get done? The next half of the meeting is concerned with the “how”. How the requirements specified in the previous session will be completed and how the sprint goal will be fulfilled. Estimates for tasks are also defined.
Overview of Sprint Planning Meeting
During the sprint planning meeting, the product owner explains the sprint goal to the team. They then collaboratively work on deciding what work is required to achieve that goal. If there are any items on the product backlog that need to be estimated, this is taken up as a first step. The requirements are then broken into manageable units of work. From this backlog the team forecasts how much work they can complete. This forecast yields the sprint backlog. The sprint planning meeting usually lasts for about two hours for each week of a sprint.
Importance of Sprint Planning
The sprint planning meeting has two main deliverables -the sprint goal and the sprint backlog. The scrum team decides how much work can be done during a sprint. This ensures that they are not pressured by anyone to do more. This improves ownership and accountability. This also results in better time estimates, as those actually involved in the work provide the estimates. Sprint planning also defines the patterns that developers will use for coding. This eliminates coding in isolation, code duplication and technical debt. It pushes developers to think about other in-progress user stories.
How to Run a Sprint Planning Meeting
1. The Agenda and Introduction
Set the right tone for the meeting. Communicate the meeting purpose to all attendees. Define what goes into the meeting agenda. The sprint planning meeting agenda must include
- Define the sprint goal
- Describe the requirements to be built (the top priority items from the product backlog)
- Determine the requirements that will be built during the sprint.
- Break down requirements into tasks with estimates
2. The Right People
It is important to have one person wholly dedicated to the product as the product owner. He should be an able communicator and understand what is required of the product. Also nominate the scrum master, who will mentor the team. Everyone on the project development team should be involved in the sprint planning process.
3. Product Backlog
The product backlog is a list of features arranged in order of priority. It also contains a brief description of desired features, called user stories as they define requirements from a user’s perspective. The product backlog contains everything related to the product such as improvements, bugs and issues. It also contains technical work and acquired knowledge. Encourage everyone on the team to add to the backlog. However, prioritizing items on the backlog should be done only by the product owner.
During the meeting
1. Determine the Goal
Write and share a brief statement of what will be achieved during the sprint. Then, the highest priority items on the product backlog that support the goal can be chosen. To drive greater commitment, the product owner and the team must work together while defining the goal. While developing the goal ensure that the focus is on the bigger picture and not just completing and delivering a ton of unrelated features. Also, ensure that that the goal facilitates measurement of sprint success.
2. Determine Requirements that will be Picked
Define story points for each requirement based on the time and effort required. This can be used to determine the target velocity. Looking at the velocity from previous sprints can help derive a better time estimate. A brief description of each requirement along with a measure of success can further help in picking requirements from the product backlog. A few items can be designated as stretch tasks that can be taken up if the team finishes early.
3. Break Items into Tasks
The requirements for each product backlog item is considered and it is broken down into tasks. The product owner need not be present for this part of the meeting. The team can work on defining tasks and the scrum master can check if the level of detail is sufficient. Ask these questions to help determine tasks
- What should I do to get started?
- What should I do next? and
- What next?
Determine the estimate for these tasks in hours. Limit the duration of tasks to less than a day, so that progress can be measured on a daily basis. Agree on the definition of done, so it’s easy to measure when a task is completed.
4. Determine Team Capacity
Before finalizing the sprint backlog, consider the number of productive hours each team member contributes. Consider the calculations below
- For a two week sprint, that is, 10 days- 1 day is spent in meetings -sprint planning, demo meeting, backlog grooming, etc.
- An individual is considered to be productive for 6 hours a day.
- So each team member is productive for 54 hours in a two-week sprint.
Also, include holidays and leaves while determining team capacity. The hours available for each team member multiplied by the number of team members gives the sprint budget.
4. Commit to the Sprint Backlog
At this stage, the scope of the sprint is fixed. Each team member essentially pledges to each other that they will work towards achieving the sprint goal. Compare the total of all the task estimates with the number of hours available (the sprint budget). Remove low priority items, if the estimate exceeds the sprint budget. This yields the sprint backlog.
Mistakes to avoid in a sprint planning meeting
1. Too much focus on getting the perfect task estimate
Teams should instead focus on the right items from the product backlog to work on during the sprint. It’s not necessary to even get the tasks right the first time, tasks can be added to the user stories and irrelevant tasks can be removed.
2. Don’t start without a product backlog
A detailed and thorough product backlog will drive high velocity and high value delivery. Ensure that it is ready before proceeding to the sprint planning phase. Regular product backlog grooming meetings can drastically reduce the time required for sprint planning meetings. Regular grooming ensures that only the most important items are present in the backlog.
3. Don’t meet without the product owner present
The product owner has to be available and committed to the sprint planning process.The product owner serves as a source of information from the customers to the development team. Not having this critical source of information can lead to low quality deliverables and costly rework.
MeetNotes is geared towards simplifying the sprint planning process. Use the sprint plans meeting template to arrive at an effective sprint goal. Define tasks and create a precise sprint backlog. Make your sprints successful.
If you are implementing the agile methodology in your organization, our blog A Lightweight Framework to Use Agile Scrum Management Practices will provide a simple framework that you can use.