A product backlog may represent many weeks or months of work, which is much more than can be completed in a single, short sprint. To determine the most important subset of product backlog items to build in the next sprint, the Scrum team performs sprint planning. During sprint planning the Scrum team agrees on a goal for the sprint, and the development team determines the specific product backlog items that are aligned with that goal and that it can realistically deliver by the end of the sprint.
Sprint planning is a recurring, just-in-time activity that takes place at the beginning of each sprint, when we can leverage the best possible information to decide what to work on in the upcoming sprint (see Figure 19.1).
For a two-week to month-long sprint, sprint planning should take no longer than four to eight hours to complete.
The full Scrum team collaborates during sprint planning
Approaches to Sprint Planning
Two-Part Spring Planning
During part 1 (the “what” part) the development team determines its capacity to complete work and then forecasts the product backlog items that it believes it can deliver by the end of the sprint. So if the team believes it can accomplish 40 story points, it will select about 40 story points’ worth of work.
During part 2 (the “how” part) the team acquires confidence in its ability to complete the items that it forecasted in part 1 by creating a plan. Most teams create this plan by breaking the product backlog items 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 com- mitment was realistic.
One-Part Sprint Planning
Using this approach, the development team begins by determining its capacity to complete work. Based on available capacity, the sprint goal may need to be refined. Next the team selects a product backlog item and then 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 until the team is out of capacity to do any more work. At that point the commitment is finalized and sprint planning is over.
An important first activity during sprint planning is determining the available capacity of the team to perform work during the sprint. Knowledge of capacity guides the Scrum team in determining what it can deliver.
What is capacity?
Let’s say a team is doing a two-week (ten-day) sprint. Right away, we must accept that the team doesn’t actually have ten days to dedicate to sprint execution. We know, for instance, that on a two-week sprint about a day of that time needs to be reserved collectively for sprint-planning, sprint review, and sprint retrospective activities. We also know that the team should reserve up to 10% of its time to assist the product owner with product backlog grooming (writing and refining, estimating, and prioritizing product backlog items) to help ensure that the items are ready.
The team must also determine how much time it should reserve for work outside the sprint, things like supporting the current product, maintaining another product, or other work unrelated to the current sprint. The team should also remember that in an eight-hour day, team members really don’t have a full eight hours to work on product backlog items. There is some overhead required to be a good citizen of the organization—attending meetings, responding to emails, interruptions, and so on.
Next, the team needs to know if people have personal time off scheduled during a sprint because that also reduces overall team capacity.
After removing time dedicated to other Scrum activities, work outside the sprint, and personal time off, what remains is the capacity of the team to work on product backlog items for this sprint. However, from this total capacity we should reserve some buffer against things not going quite as planned. For example, any estimating we do won’t be perfect, so items might turn out to be a bit larger than we thought. Or something can (and usually does) go wrong. Having a bit of buffer against unexpected problems is wise.
Capacity in Story Points
A team’s velocity is expressed in terms of product backlog item units (let’s say story points). So, if we express capacity in story points, determining capacity is the same as predicting our team’s target velocity for the upcoming sprint.
To make this determination, start with the team’s long-term average velocity or the team’s previous sprint velocity (sometimes referred to as the “yesterday’s weather” approach) as an initial estimate of its capacity/velocity for the upcoming sprint. Then consider whether the upcoming sprint might differ from typical or previous sprints (it might not). The result is a reasonable adjusted capacity (predicted velocity) for the upcoming sprint.
Capacity in Effort-Hours
The capacity calculation shown in Table 19.2 is derived as follows. First, the team members express how many days they have available to work on the upcoming sprint (the amount of unavailable time equates to the “personal time off” slice in Figure 19.5). Both Betty and Rajesh are planning to attend a two-day training class, so each of them has only eight days available in the sprint. Simon is planning a three-day weekend so he has nine available days.
Next, the team members determine how much time to reserve for other Scrum activities. They reserve a day of time for sprint planning, sprint review, and sprint retrospective activities. They also deduct the time needed to assist the product owner with product backlog grooming activities. Together these represent two fewer days
available per person to perform task-level work.
The team members then determine how many hours per day they could dedicate to work in this sprint. Each person gives a range that takes into account any overhead work not associated with items in the sprint backlog (the overhead equates to the “other non-sprint commitments” slice in Figure 19.5). For example, Simon is only half-time on this product, so he estimates only two to three hours a day to work on this product during the sprint.
After accounting for personal time off, other Scrum activities, and non-sprint commitments, the team in Table 19.2 estimates a capacity of 140 to 197 effort-hours to work on tasks in the sprint backlog. I would caution this team against taking on 197 hours of work because it would leave no sprint buffer. A better strategy for this team would be to use a capacity that is probably greater than 140 hours but certainly less than 197 hours when committing to work during this sprint.
Selecting Product Backlog Items
If we have a sprint goal, we would select product backlog items that align with that goal. If there is no formal sprint goal, our default is to select items from the top of the product backlog. We would start with the topmost item and then move to the next item and so forth. If the team were not able to commit to the next-highest-priority item (perhaps there is a skills capacity issue), it would select the next appropriate higher-priority backlog item that looks as if it can be completed within the constraints.
One of my rules when selecting product backlog items for a sprint is that we don’t start what we can’t finish. So if the next product backlog item is too big to complete in the sprint given the other items that we have already agreed to complete, we should either try to break down the next item into two or more smaller items, each of which would be valuable to our customers, or consider working on another item that we can complete. Also, having a good definition of ready will prevent product backlog items from being selected that are poorly defined or have unfulfilled resource or depen- dency constraints that would prevent our finishing them in a sprint.
One way to acquire confidence is to use predicted velocity to see if the commitment is realistic. If the predicted sprint velocity is 25 story points and our team has selected 45 story points’ worth of work, the team should be concerned. At the very least we should start asking questions about why we think the commitment can be achieved. When used this way, velocity provides an excellent check and balance on the pro- posed commitment.
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 predicted sprint velocity is 25 story points and the team’s commitment totals 21 story points, the commitment would seem reasonable. However, until we dig a little deeper to the task level, we don’t really know if the set of product backlog items that total 21 story points can actually be completed—there could be dependency issues, skills capacity issues, as well as a host of other issues that make it impractical for the team to get them all done.
Most Scrum teams gain the necessary level of confidence by breaking the product backlog items down into the tasks that are required to complete them to the Scrum team’s agreed-upon definition of done. These tasks can then be estimated (usually in effort-hours) and subtracted from the team’s capacity. Breaking product backlog items into tasks is a form of design and just-in-time planning for how to get the items done.
Refine Sprint Goal
The sprint goal summarizes the business purpose and value of the sprint. The product owner should come to sprint planning with an initial sprint goal. That initial goal, however, can be refined during the course of sprint planning as the sprint-planning participants work together to determine what can realistically be delivered.
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. The sprint goal and the selected product backlog items embody that commitment.
Sprint execution is the work the Scrum team performs to meet the sprint goal.
Sprint execution is like a mini project unto itself—all of the work necessary to deliver a potentially shippable product increment is performed.
During sprint execution the development team members self-organize and determine the best way to meet the goal established during sprint planning.
The ScrumMaster participates as the coach, facilitator, and impediment remover, doing whatever is possible to help the team be successful. The ScrumMaster doesn’t assign work to the team or tell the team how to do the work. A self-organizing team figures these things out for itself.
The product owner must be available during sprint execution to answer clarifying questions, to review intermediate work and provide feedback to the team, to discuss adjustments to the sprint goal if conditions warrant, and to verify that the acceptance criteria of product backlog items have been met.
Sprint Execution Planning
During sprint planning the team produces a plan for how to achieve the sprint goal. Most teams create a sprint backlog, which typically lists product backlog items and their associated tasks and estimated effort-hours (see Figure 19.6). Although the team probably could create a full task-level sprint execution plan (the equivalent of a project plan for the sprint, perhaps in the format of a Gantt chart), the economics of doing so are hard to justify.
It’s the team’s responsibility to manage the flow of work during sprint execution to meet the sprint goal. It must make decisions such as how much work the team should do in parallel, when work should begin on a specific item, how the task-level work should be organized, what work needs to be done, and who should do the work.
Parallel Work and Swarming
An important part of managing flow is determining how many product backlog items the team should work on in parallel to maximize the value delivered by the end of the sprint. Working on too many items at once contributes to team member multitasking, which in turn increases the time required to complete individual items and likely reduces their quality.
Figure 20.3 shows a simple example that I use in my training classes to illustrate the cost of multitasking.
The goal is to complete two identical tables by writing the letters a to j, the numbers 1 to 10, and Roman numerals i to x. One table is completed a row at a time, and the other is completed a column at a time. The row-at-time table represents multitasking (do the letter task, then do the number task, then do the Roman numeral task, and then repeat the sequence for the next letter, number, and Roman numeral). The column-at-a-time table represents single tasking.
The typical results shown in Figure 20.3 are that most people complete the col- umn-at-a-time table in about half the time of the row-at-a-time table.
A term frequently used to describe this approach is swarming, where team members with available capacity gather to work on an item to finish what has already been started before moving ahead to start work on new items. Teams with a Musketeer attitude and some degree of T-shaped skills swarm. Teams that still think in terms of individual roles wind up with some members far ahead and others who are mired in unfinished work. A classic individual-role-focused thought is “The testers might still have ‘their’ work to finish up, but I’m finished coding this feature, so I’m off to start coding the next one.”
Some people mistakenly believe that swarming is a strategy to ensure that team members are 100% busy. This is not the goal of swarming. If we wanted to ensure that people were 100% busy, we would just start working on all product backlog items at the same time! Why don’t we do that? Because the extensive multitasking required to make that happen would ultimately slow the flow of completed items. Swarming, on the other hand, helps the team remain goal focused instead of task focused, which means it gets more things done, faster.
Which Work to Start
The simplest way to select the next product backlog item is to choose the next highest-priority item as specified by the product owner (via the item’s position in the product backlog). This approach has the obvious advantage of ensuring that any items not completed during the sprint must be of lower priority than the ones that are completed.
What Work Needs to Be Done?
What task-level work does the team perform to complete a product backlog item? Ultimately the team decides. Product owners and managers must trust that the team members are responsible professionals who have a vested interest in doing great work. As such, they need to empower these individuals to do the necessary work to create innovative solutions in an economically sensible way.
Of course, product owners and managers do have influential input to what task level work gets done. First, the product owner ensures that the scope of a feature and its acceptance criteria are defined, both of which provide boundaries for the task-level work. Overall, the product owner must work with the team to ensure that technical decisions with important business consequences are made in an economically sensible way.
Who Does the Work?
There are a number of factors that can and should influence who will work on a task; it’s the collective responsibility of the team members to consider those factors and make a good choice.
The daily scrum is a critical, daily inspect-and-adapt activity to help the team achieve faster, more flexible flow toward the solution. The goal of the daily scrum is for people who are focused on meeting the sprint goal to get together and share the big picture of what is happening so that they can collectively understand how much to work on, which items to start working on, and how to best organize the work among the team members. The daily scrum also helps avoid waiting. If there is an issue that is blocking flow, the team would never have to wait more than a day to discuss it.
Task Performance—Technical Practices
One of the benefits of working in short timeboxes with small teams is that you don’t need complex charts and reports to communicate progress!
The task board is a simple but powerful way to communicate sprint progress at a glance. Formally, the task board shows the evolving state of the sprint backlog over time.
Sprint Burndown Chart
Each day during sprint execution team members update the estimate of how much effort remains for each uncompleted task. We could create a table to visualize this data. Table 20.1 shows an example of a 15-day sprint that initially has 30 tasks (not all of the days and tasks are shown in the table).