Sprint Planning Definition
Sprint planning is a time set aside at the beginning of each sprint for the Scrum team to decide what work they will complete in the upcoming iteration. During a sprint planning meeting, Scrum and agile teams accomplish three things:
- Discuss how to implement a set of product backlog items
- Determine which set of product backlog items the team can commit to complete during the sprint (or iteration). These items and their tasks become the sprint backlog.
- Choose and fine-tune the sprint goal to reflect the work of the sprint.
Getting Started with Sprint Planning (Part of our free Scrum Foundations video series.)
What Is the Goal of Sprint Planning?
The purpose of sprint planning is 1) to select the right set of product backlog items to work on during the sprint and 2) to discuss each item enough to feel confident beginning work.
Sprint planning is a time for the team to consider how they will approach doing what the product owner has requested. By contrast, story-writing workshops are when the product owner, stakeholders, and team brainstorm what functionality the customer needs most.
By the end of sprint planning, the team selects how much work they can do in the coming sprint. The product owner does not get to say, "We have four sprints left so you need to do one-fourth of everything I need." It's up to the team to determine how much they can do in the sprint.
Stop Playing It Safe: An Agile Team Shouldn't Finish Everything Every Iteration
Who Attends Sprint Planning?
The sprint planning meeting is attended by the entire Scrum team, including the product owner, Scrum Master. Outside stakeholders may attend by invitation of the team, although this is rare.
How Long Does Sprint Planning Take?
How long sprint planning lasts depends on the sprint length.
The official answer from the Scrum Guide is that sprint planning can take no more than 8 hours (usually less for shorter sprints).
Eight hours is far too long to spend planning.
Instead, target about 45 minutes of meeting time multiplied by the number of weeks in the sprint. So a two-week sprint should have a 90-minute sprint planning meeting. And a full four-week sprint (or one month sprint) should target a 3-hour sprint planning timebox.
It's OK if a team's first few planning meetings take a bit longer than this. In fact, it’s likely they will. But 45 minutes times the number of weeks is a good target for a team with a bit of experience.
If your teams are taking too long to plan, it's likely you are making one of the classic sprint planning mistakes: trying to identify every last task.
Comprehensive task lists and precise estimates are not the goal of sprint planning meetings. The purpose of sprint planning is to select the right set of product backlog items and have a rough idea of how to work on them. The team does not need to know every task they'll perform to accomplish this goal. And the team certainly does not need to know if one of those tasks will take 5 hours instead of 4.
What Happens in Sprint Planning?
During the sprint planning meeting, the product owner describes the highest priority features to the development team.
Then, sprint planning works in one of two general ways: by considering a team's historical velocity or by considering a team's capacity. Capacity planning is the better choice for sprint planning. Let's explore velocity and capacity planning to understand why this is true.
Capacity vs Velocity Based Planning
Capacity-driven planning starts with the product owner giving an overview of the set of high-priority items or user stories from the product backlog that could be brought into the sprint.
Team members select the first item. The team asks enough questions to understand what is required. They then break that item down into individual tasks.
Team members roughly estimate the hours (not story points) to do each task. Then, with their overall team capacity for the sprint in mind, they ask themselves if they can commit to deliver the product backlog item. (They remember not to overfill their sprint, because they know they can't think of every task during planning, and that's OK.)
If the answer is yes, they add that product backlog item and its tasks to the sprint backlog. They then ask themselves if they have enough capacity to consider another product backlog item.
If they do, team members grab the next most important product a backlog items from the product owner's list and repeat the process.
If the team decides they cannot commit to another product backlog item, they have several choices:
-
Look for ways to split a product backlog item into multiple, smaller size items
-
Choose a different product backlog item, or
-
Declare the sprint full.
During capacity-based sprint planning, there is no discussion of story points or velocity. It's just about determining the sprint commitment. The developers decide how much they can commit to by breaking product backlog items into tasks. They estimate each of these tasks in hours.
Contrast that with velocity-driven sprint planning. With velocity-based sprint planning, the team selects the number of product backlog items that equals their average velocity over time (historical velocity).
Some teams stop there. Others double check that they can commit to those items by breaking them down into tasks and estimating those tasks in hours to see if the amount of work is in line with past sprints.
Velocity Is Not Ideal for Sprint Planning
One problem with velocity-based sprint planning is that velocity bounces around from sprint to sprint. For example, suppose a basketball team is in the middle of their season. They've scored an average of 98 points per game through the 41 games thus far.
It would be appropriate for them to say "We will probably average 98 points per game the rest of the season." It would not be accurate for them to say before any one game, "Our average is 98 therefore we will score 98 tonight." Velocity is a useful long-term predictor but is not a useful short-term predictor.
That's just one of a couple reasons why capacity-driven planning is preferable to velocity-driven sprint planning.
Consider Flow of Work in Sprint Planning
Agile teams learn how to overlap work and minimize the size of handoffs between team members. Despite this, some product backlog items will require a week or more of programming time before the programmer can give something even beginning to be testable to a tester.
That’s OK. Not everything can be split as small as we might like.
To help ensure everyone has something to do early in the sprint and to avoid having multiple product backlog items wrap up the last few days of the sprint, good scrum teams learn to mix the size of product backlog items they bring into each sprint.
For example, a software development team might mix large-scale programming tasks with small, easy to implement items. That way, a few programmers can work on the smaller items, ensuring a smooth flow of work to testers early in the sprint. The rest of the programmers can work on the large items, handing them over to testers whenever possible.
Do Teams Have to Identify & Estimate Tasks?
Remember, when it comes to sprint planning in agile, the purpose is not to identify tasks. The purpose also is not to estimate the number of hours for each of those tasks.
The purpose of planning a sprint is for the team to arrive at a commitment to some set of functionality that they feel reasonably confident they can complete in the coming iteration.
Some teams split all work up such that all tasks are "about half a day." They then can skip explicitly estimating the hours for each task because, in a way they've already done it. But most teams need tasks and estimates to feel confident in making a commitment to a set of product backlog items.
Some amount of estimating and planning is necessary for all agile teams. The approach to these estimation activities can (and should) be as lightweight as possible.
Assigning Tasks During Sprint Planning
Ideally, teams leave sprint planning without having put names on tasks. Following a real-time sign-up strategy allows more flexibility during the sprint.
Starting a sprint without names on any tasks can be unsettling to teams and ScrumMasters who are new to Scrum. Start scaling back by asking people to sign up for only about half of the tasks in the sprint.
Do this for two sprints. After two sprints, have team members sign up for only one-fourth of the total tasks in the sprint. At this point, the team will start to see most of the benefits of a real-time sign-up strategy.
What Are the Inputs to Sprint Planning?
A refined and estimated set of product backlog items is the primary input to sprint planning.
New stories might have been added to the product backlog as a result of sprint review feedback. Different stories might exist on the product backlog after those stories were split. Estimates should be put on any new, high-priority stories prior to sprint planning. The product owner needs estimated product backlog items to prioritize.
A good guideline is for the product owner to come to the sprint planning meeting prepared to talk about two sprint's worth of product backlog items.
Another input to sprint planning is either team capacity (if using capacity planning) or historical velocity (if using velocity planning methods).
What Are the Outputs of Sprint Planning?
There are two artifacts that result from a sprint planning meeting:
-
A sprint goal (Find out why sprint goals should be optional.)
-
A sprint backlog
A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint and why it is valuable to stakeholders. It is written collaboratively by the team and the product owner. Sprint goals are not stretch goals.
The sprint backlog is the other output of sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of many of the tasks necessary to deliver those product backlog items. The sprint backlog can and will evolve during the sprint as the team learns more about the work being done. The team can and will add more tasks to their original list.