Chapter 19: Sprint Planning

Product backlogs typically contain much more work than can be completed in a single sprint. So, each sprint begins with sprint planning.

Sprint planning is a recurring, just-in-time activity that occurs at the beginning of each sprint, when the entire Scrum team gathers to agree on a sprint goal and to select a subset of product backlog items it can commit to accomplish during the sprint. For a two-week to month-long sprint, sprint planning should take no longer than four to eight hours to complete.

The participants, inputs, outputs, and basic process of sprint planning are shown in the image below.

Participants in Sprint Planning

The full Scrum team collaborates during sprint planning. This includes the development team, the product owner, and the ScrumMaster.

Inputs to Sprint Planning

Sprint planning relies on a set of inputs that guide the development team in determining what value it can realistically deliver during the sprint. These sprint planning inputs are as follows:

• Product Backlog. The highest priority PBIs should already be groomed, which typically means the PBIs have acceptance criteria, and have been sized appropriately, estimated, and prioritized.
• Team Velocity. The team's historical velocity is one indicator of how much work is practical for the team to complete in a single sprint.
• Constraints.The team should have identified any business or technical constraints that could materially affect what the team's can deliver.
• Team Capabilities. The team should know which team members are available (and what their availability is) for this particular sprint, as well as which skills each team member has.
• Initial Sprint Goal. The product owner should have identified the business objective he ideally would like to see accomplished during the sprint.

Outputs of Sprint Planning

At the end of sprint planning, the development team communicates its commitment through the two sprint planning outputs: a finalized sprint goal and a sprint backlog.

Sprint Planning Process

The process of sprint planning can be accomplished in several ways, but in general there are two approaches to sprint planning: two-part sprint planning and one-part sprint planning. Both approaches begin with the team determining its capacity.

Determine Team Capacity

Put simply, a team's capacity is the estimated total number of hours the team will have available to work on product backlog items during the sprint, minus other regular sprint activities, non-sprint commitments, and planned time off. The capacity should take into account individual team member skills as well, especially highly specialized skills that might have very limited availability during a sprint. Most teams also reserve some buffer time against the unplanned and unexpected.

Capacity can be measured in story points or in effort hours. I recommend effort hours, because I prefer the team to acquire confidence in its commitment by breaking the stories into tasks, which are estimated in terms of hours. I'll discuss the reasons why a bit later.

Choose An Approach to Sprint Planning

Before delving into how a team acquires confidence, I want to share two ways to structure sprint planning. The first structure for sprint planning is a two-part approach, divided into the what and the how. During part 1, the team determines its capacity to complete work and forecasts the PBIs the product owner has requested that it believes it can deliver by the end of the sprint. Then, in part 2, the team acquires confidence in its ability to complete the items it forecasted in part 1 by creating a plan.

Many teams complete their plan by breaking the PBIs into a set of tasks and then estimating (in hours) the effort required to complete each task. The team then compares the estimate of task hours against its capacity, in terms of hours, to see if its initial commitment was realistic.

If the team finds it has selected too much or too little, or has selected items that cannot realistically be developed together in the same sprint, it can adjust its forecast and possibly refine the sprint goal accordingly. When the team's forecast is comfortably within its capacity range and constraints, it finalizes its commitment and sprint planning is over.

An alternative structure for sprint planning, and the one I use most frequently, is a one-part approach that interleaves selecting an item and acquiring confidence that it can be delivered.

Using this approach, the development teams begins by determining its capacity to deliver work. Based on available capacity, the sprint goal may need to be refined. Next, the team selects the highest priority requested product backlog item and acquires confidence that the selected item will reasonably fit within the sprint, given other items already included in the team's evolving commitment. This cycle is then repeated in priority order until the team is out of capacity to do any more work. At that point, the team finalizes its commitment and sprint planning is over.

Acquire Confidence

One way a team can acquire confidence in its ability to deliver a set of product backlog items during the sprint is to use historical velocity to see if the commitment is realistic. A sprint backlog that exceeds a team's historical velocity average should be a red flag. The risk of using velocity as the sole means of establishing confidence is that even though the numbers look right, the commitment might still be unachievable.

For example, if the team's historical velocity is 25 story points and the team is looking at a 21-point sprint backlog, the commitment would seem reasonable. However, until we dig a little deeper into the task level, we don't really know what dependency, skills capacity, and other issues lurk beneath the surface of a PBI. That's why I prefer breaking the product backlog items down into the tasks that are required to complete them, as defined by the Scrum team's definition of done. These tasks can then be estimated and subtracted from the team's capacity, if the capacity has been expressed in effort hours. Breaking product backlog items into tasks is a form of design and just-in-time planning for how to get items done.

Refine the Sprint Goal

The sprint goal summarizes the business purpose and value of the sprint. The product owner comes to sprint planning with an initial sprint goal, but the sprint goal would be refined over the course of sprint planning to match the reality of what can be delivered during the sprint.

Finalize the Commitment

At the completion of sprint planning, the development team finalizes its commitment to the business value it will deliver by the end of the sprint. This commitment is expressed in a refined sprint goal and sprint backlog.

Closing

This chapter describes the sprint planning process that begins each sprint. The next chapter will discuss the details of how sprints are executed once they have been planned.