Scrum Rituals: Sprint Planning
The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
The ritual that marks the beginning of each sprint is called sprint planning. Sprint planning is hosted by the scrum master, but the person responsible for most of the content that goes into a sprint planning is the product owner.
The purpose of the sprint planning is to set the agenda for the upcoming sprint. The team gets together with the product owner and the scrum master to get an introduction to the stories that should be completed during the next sprint.
The product owner shows how the stories fit into the vision for the product, and the team estimates the stories the product owner has introduced and commits to completing as many as they believe they’re capable of, given their historical velocity—which is determined by the number of points they’ve been able to complete in an average sprint. At the end of the sprint planning there should be a commitment to a certain set of stories that everyone can agree on. The stories should all be clear, and the amount of work they represent should be within the capacity of the team to complete during the next sprint.
Depending on the number of weeks a team has committed to for each sprint, the sprint planning may take several hours, or it may take an entire day. For a two-week sprint, a team may find that setting aside three or four hours is a good investment for a sprint planning. That might seem like a lot of time, but sprint planning done right is very detailed and explicit about what the team needs to produce. A key value of scrum is the communication it facilitates. Sprint planning exemplifies this.
Most teams will find they’re able to accomplish the objectives of these rituals more efficiently as they get more familiar with the process. Having a strong scrum master who maintains a clear time box around the different aspects of the ritual can help make the process go as smoothly as possible.
But there’s a lot to get done during the sprint planning, and these rituals need to be given adequate room to accommodate all the issues that will come to the surface. Starting with clear time constraints gives everyone confidence that there’s a goal and an end point in mind, and also helps keep people focused.
In preparation for this ritual, the product owner will have been working with designers, customers, various team members, and the scrum master to create a backlog of clear and specific stories that have the highest priority for the product.
It’s the responsibility of the product owner to make sure each of these stories is ready to be worked on, and phrased in such a way that any team member can read and understand each story’s description and acceptance criteria.
Introducing New Stories
Sprint planning provides the opportunity for the scrum team to get an introduction to the stories the product owner wants them to work on for the next iteration of the product. During this part of the ritual, the product owner goes over the stories that have been prepared, presenting them to the team for evaluation.
It’s important for every member of the team to participate actively during this presentation, because this is their opportunity to question and challenge the completeness and appropriateness of each story. A good product owner will have discussed the stories with experts on the team before this ritual, to make sure that predictable objections have been addressed.
Sprint planning encourages active discussion around each story. The process opens up a dialogue, allowing the product owner and the team to consider the ramifications and feasibility of each story in detail. Although the product owner is authorized to set the priority of the stories on the sprint backlog, the team has the authority to reject stories that it considers impossible, inadequately defined, or technically inappropriate before they’re added to the sprint backlog.
This part of the sprint planning ritual is also when the team has the responsibility to present stories that relate to the code itself. If the product owner is responsible for the vision of the product, the development team is responsible for the quality and maintainability of the code. The product-oriented focus of scrum is not an excuse to ignore technical debt.
Often the team will introduce stories around refactoring code, updating code to meet new standards, or making crucial upgrades to the infrastructure. It’s important for the team to make a strong case, because the product owner has ultimate authority. Different teams resolve this balance of power in different ways, and it’s up to each team to figure out how best to address technical debt while still meeting the expectations of product development.
The next phase of sprint planning is story estimation. During this process, the team will estimate the relative level of effort required to accomplish each story, based on the team’s experience with similar stories in the past and their agreed definition of done.
There are many ways that teams estimate stories. The important thing to keep in mind when estimating is that the values assigned to the different stories are arbitrary and relative, and bear no resemblance to actual time. The point of the estimating exercise is to improve the team’s ability to look at a new story and figure out how much effort it’ll take relative to other stories they’ve already worked on.
Most teams use a system of points to estimate stories. A smaller, easy story may be estimated at one point, while a large or complex story may be assigned 20 points. Many teams use a modified Fibonacci scale, with the numbers 0, 1, 2, 3, 5, 8, 13, and 20 representing increasing levels of effort. The goal over time is for the team to get a sense of how many points they can accomplish within the single sprint, so they can estimate forward more effectively.
Each team comes up with its own sense of what every point value means for itself. There can be no logical comparison between the points accomplished by one team during the sprint and the points accomplished by a different team during the same sprint. The value of the points is subjective, and relevant only to the participants of a specific team.
Other systems for sizing stories include T-shirt sizing—such as small, medium, large, extra-large. It’s completely up to the team what system they choose. Once the team has chosen a system, they should try to stick with it for several sprints, so that they can start to get a sense, over time, of what their velocity is in the metric they’ve chosen.
Note: Everyone Should Agree
It’s important for everybody on the team to agree to the point estimate for a story, regardless of whether every member of the team will be working on that particular story. This is part of the transparency of scrum. Everyone on the team should be able to understand every story well enough to estimate its relative level of effort, and when one team member is working on a story, everyone should have at least a concept of what that story is.
Other stories that are usually not assigned points are bugs. A bug has a specific definition in scrum, and it has nothing to do with unexpected or unwanted behavior in an existing product. Bugs in scrum are missed requirements for stories that are still in progress, or that have already been accepted as done in a prior sprint.
If the team has completed a story, and it was accepted, and the points were included in the total for a sprint, but it later turns out the story was not completed correctly, no points are assigned for fixing the bugs to bring the story to a done state.
Bug work does take away from the team’s velocity, because it addresses points that were included in the velocity calculation inappropriately. That should be true regardless of whether the bug is fixed in the same sprint or in a subsequent sprint. As long as the team received points for a story that didn’t meet the acceptance criteria, the work to get it to the true done state shouldn’t count toward the points in any sprint.
Note: You Don’t Need to Set Aside Capacity for Bugs
It’s not necessary to set aside a percentage of the team’s capacity to deal with bugs. The amount of work the team can predictably complete in a typical sprint includes the effort applied to fixing bugs when stories were accepted as done, but didn’t actually meet all the acceptance criteria.
There’s an old joke that scrum is a system for improving a team’s ability to ship technical debt. Certainly there’s more to developing a web or mobile application than just tacking on a bunch of features onto an ever-growing, increasingly complex code base. Eventually that code needs to be re-factored, infrastructure changes will have to be worked on, and a team won’t be able to do effective work on new features until these issues are addressed. These necessary improvements may have no specific value for the customer, but they are necessary to keep the code from becoming stale or difficult to maintain.
Tasks relating to code maintenance should be included in the work done by the team, and prioritized in the sprint backlog, but should not be estimated with points. The points in scrum measure the ability of the team to deliver value to the customer, and are related to feature development. They are not a measure of the overall amount of work the team is doing.
A task usually does not deliver any tangible user value. But tasks need to be done, and a negotiation needs to happen between the team and the product owner during the sprint planning if the team recognizes that necessary work to keep systems maintainable and avoid technical debt is being deferred in favor of new features.
Most of the stories that make it to a sprint planning should be within the technical capability of the team, but occasionally there will be stories that require deeper research. Such stories trigger new tasks called spikes. Spikes are usually not assigned points. However, a proper spike does have acceptance criteria. There should be a clear and agreed outcome for any spike.
Spikes take away from the resources of the team, while individuals go and research technical solutions that may be beyond the team’s current capabilities. As a result, the more spikes that are required to accomplish the goals of the product owner, the lower the number of points the team can accomplish in a sprint.
Due to the unknown nature of spikes, they can eat up a lot of a team’s resources unless they’re constrained. Generally, when agreeing to include a spike in a sprint, the team will decide on a maximum amount of time and effort that can be committed before the spike must be concluded or abandoned.
Committing to a Sprint Backlog
Once all the stories that the product owner has presented have been estimated, all the participants in the ritual work together to come up with a backlog that makes sense for the upcoming sprint. This backlog will be sized based on the historical number of points that the team has been able to accomplish in the past, balanced against the point estimates for the new stories.
While the product owner has final authority over the contents of the sprint backlog, as well as the order of the sprint backlog, the team has the opportunity to advocate for certain changes while the backlog is being prepared.
For example, although each story should stand alone, it may make sense to the team to work on particular stories in a certain order. The team may also wish to complete stories that were started but not finished in the previous sprint. Completing stories that are in progress is useful for the development team because it helps them to maintain continuity. While there’s a cost to loss of continuity, that cost is the responsibility of the product owner, and the product owner has the authority to make those decisions for the sake of the product.
Once a final sprint backlog has been created, everyone on the team needs to commit to that backlog. This is the last opportunity for the team to object, or raise issues that they think may have an impact on their ability to do the work required. If there’s still disagreement, the scrum master needs to step in and facilitate the conversation so that agreement can be reached.
The end product of a sprint planning is a sprint backlog that everyone on the team can agree to. The scrum master should poll the room to make sure everyone agrees that the commitment is realistic, and that they are willing to take it on for the upcoming sprint. Then the new stories should be entered in order of priority into the tracking tools the team has agreed to use for the sprint backlog.
Sprint planning reminds everybody exactly where they are in the process of building the product owner’s vision for the product, and what the objectives are for the upcoming increment. At the end of sprint planning, everyone on the team should have a good sense of what they need to do next, and a firm commitment to a set of prioritized stories to complete over the duration of the upcoming sprint.