How to Do Effective Sprint Planning for a Scrum Team

We don’t plan. We do Scrum, so we just execute.

I hear this all the time. People think that Scrum and agile mean no planning, no estimating, no meetings, no anything! This could not be further from the truth. We plan at a variety of levels in an agile project: the daily plan or daily standup, the weekly plans (Sprint, or iteration, backlog), the release plan (the product backlog), and potentially more.

Let’s focus on planning a Sprint.

Forecasting versus Committing

In the summer of 2011, Ken Schwaber and Jeff Sutherland revised the Scrum Guide. In it, they removed one long established behavior known to Scrum, which is the commitment the team makes to the Product Owner and the customers. Commitment was replaced by forecast. They say that teams may forecast their work, but not commit to it.

While I understand their logic, I prefer commitment for the following reasons:

• Committing to something puts the team in a different mindset than just forecasting. If a team forecasts, it is implied that not meeting everything they said they could do is an acceptable behavior. While teams may learn from their forecasts, eventually having less estimation variance, I find that teams that forecast take longer to reduce the variance as compared to teams that commit.
• Forecasting, or estimating, is appropriate for the product backlog. However, when teams move stories from the product backlog to the Sprint Backlog and break them down, they are adding another level of granularity, finding out small details that allow them to ask themselves “can we commit to this?” Forecasting runs the risk of falling back to a lazy state by the team instead saying “we only need to forecast, it’s OK if we miss some stuff, we can figure it all out later.”

And on a lighter note, imagine if you said to your wife, husband, partner “I forecast that we’ll be together for ten years” versus “I commit myself to you” – yeah, that’ll go over well.

In the end, Scrum is about common sense. I suggest you try both the commitment approach and the forecast approach. This is all about learning, not about what words you use, so be smart, experiment with both and use what is best for you, your team and your company.

What Is Sprint Planning?

We hold a Sprint Planning Meeting to plan what the team will build in the upcoming Sprint and how the team will build it. Although we refer to it as the Sprint Planning meeting, teams will often break it into two parts. Part 1 focuses on what the team is being asked to build and is attended by both the Product Owner and the team. Part 2 focuses on how the team plans to build the desired functionality. If, for any reason, the Product Owner does not attend Part 2, the Product Owner should remain available for questions.

In Part 1 of the Sprint Planning Meeting, the Product Owner has the opportunity to describe a desired set of stories to the developers. This is a deep-dive session on the what portion of the stories. The Product Owner presents the stories, shows how things interact and walks through the interface. Additionally they may review infrastructure or architectural items. The goal is to fill the developers collective heads with enough information that they can begin figuring out how to build the functionality. The developers should ask a variety of questions to gather information for the how meeting - questions such as:

• “What is the acceptance criteria of all of these stories?”
• “What data sources do you think we are using?”
• “How should the interface look on this component?”

During Part 2 of the Sprint Planning Meeting, the developers turn their attention to building the Sprint Backlog—the list of stories and the tasks required to complete them during the Sprint. To build the backlog, the developers break down each story that the Product Owner has requested to the task level; each task is given an hourly estimate. By the end of Part 2, they decide which stories they can commit to completing during the Sprint.

Together, the two parts of the Sprint Planning Meeting can take anywhere from two to eight hours. The general rule of thumb I use is that each part should take one hour for every one week of Sprint length. That means if I am running one-week Sprints, the meeting will take a total of two hours (one hour for Part 1 and one hour for Part 2). If, on the other hand, I am running four-week Sprints, the meeting will take a total of eight hours (four hours for Part 1 and four hours for Part 2).

How Do We Accomplish It?

As long as the team leaves the Sprint Planning Meeting committed to completing a list of stories, the team has accomplished the purpose of Sprint Planning. Getting the team to the point where each team member feels comfortable making that commitment, however, requires a bit of pre-planning and facilitation.

The Product Owner has one job during Sprint Planning: come to the meeting able to describe a set of desired stories. The team’s objective is to understand the stories from the Product Owner’s point of view, to share in the Product Owner’s vision. The Scrum Master should ensure that the team is asking enough questions and capturing all of the resulting data, including acceptance criteria, sketches, and any assumptions. The Scrum Master should also let the Product Owner know that the team might have additional questions after it begins to break the questions down into tasks. Although the Product Owner presents stories whose point totals roughly corresponds to the team’s historic velocity, the team will ultimately decide whether it can, in fact, take on all of the stories in a given Sprint based on what it learns during Part 1 and Part 2 of the Sprint Planning Meeting.

After the team has obtained all of the information from the Product Owner, it must break down the stories into tasks and create a Sprint Backlog, which captures all of the stories, notes, acceptance criteria, tasks, and estimates for a particular Sprint. While there are many ways to do this, I employ the following method, which takes advantage of all of the team members’ ideas and gives everyone a voice in task decomposition.

1. Have the Scrum Master or meeting facilitator read off a story and ask, “Does everyone understand it?” The team should, as it just spent time with the Product Owner discussing it. If someone on the team doesn’t understand, spend some time re-visiting the story, asking any necessary questions of the Product Owner.

2. Next, have each team member grab a sticky pad. Ask each team member to write a single task on each sticky and toss it in the middle of the table.

   • As each sticky is tossed into the middle of the table, the thrower announces the task. So if “update stored procedure” is written, it is said out loud. This is important because it will spark ideas and cause others to say, “Oh yeah, and we need to update the data source.” At that point, someone will write on a sticky, “update data source,” say it, and throw it in the middle. This brainstorming activity really works to flush out all the associated tasks. Do not worry about duplicates at this time. Throwing out all the task stickies usually takes about five to ten minutes per story.

3. When the stickies are all on the table, it’s time to sort them. Put them all up on a wall, step back, and look—lots of stickies! Start by identifying any duplicates; overlap any stickies that seem to be duplicates. Then, look for tasks that seem to go together, either because they are similar or because they depend on each other. For example, if two stickies have a similar relationship, put them together but offset them, as the following illustration shows:

   

   If two tasks are so closely related as to be nearly identical, overlap them almost fully, as shown below:

   

   By sorting the stickies, the team can cull the list of tasks and visualize the relationships between those that remain.

4. When the tasks are sorted, it’s time to estimate. I use the planning poker technique for task estimation, with one difference: The numbers on the cards represent hours instead of points. I do this because people tend to get too hung up on needless details with regards to hours, especially on big tasks. There’s a good reason for their trepidation. Too often, companies use estimation as a stick to beat the team. “You said that would take 8 hours and it took you 12. What’s wrong?” or “You said it would take 8 hours and it took only 4. You’re padding your estimates.”

   In the same way that cards help keep story-point estimates abstract, using cards for task estimation allows the team to have the freedom that comes with having a set of fixed numbers to choose from while forcing them to ultimately make a choice. It also eliminates heated discussions of whether a task should be estimated at 6 hours or 6.5 hours or 7 hours.

   Whatever the final estimate, remember that estimation is done by the team and is intended to be used by the team only to help increase its confidence and determine whether it can accomplish the work the Product Owner has asked for based on the velocity. Task estimates are not metrics and should not be used as such. Never use estimates as a weapon against the team.

5. Now that the tasks are estimated, the team must determine if it has the capacity to take on more work. To do this, you’ll need to know the team’s capacity, the total hours the team has available during the Sprint. Determining capacity is easy if you have a fully dedicated team but gets harder if you have a team made up of part-time people who are split across multiple projects. Ask everyone to write down the number of hours each can work on the project per day (or total per the Sprint). Add all the numbers together to get the total number of hours available for the team. Let’s say the team’s capacity turns out to be 200 hours. If the sum of the tasks for a story is estimated to consume 30 hours, ask the team, “Can we pick up more work?” At this early stage, the answer is an obvious yes.

Because you have more capacity to fill, move on to the next story, and repeat steps one through five.

At some point, you’ll have a difficult time answering the question, “Can we pick up more work?” This is because you are approaching your team’s capacity. As you work through this process, consider that you don’t want to fill the Sprint to capacity. If you fill a glass with water to the brim, it’s very likely to spill. The same is true of Sprints. If the estimated hours consume all available time and a new task is identified later in the Sprint, things will spill over. You must leave room for emergent tasks.

When considering the Sprint commitment, it helps to consider retrospective data from past Sprints. Is the team consistently having to bring in more work? Perhaps the team could commit to more during Sprint Planning. Is the team consistently unable to finish all the work for a Sprint? The team might need to be more conservative with its commitments until it has addressed the root cause of the incomplete Sprints.

One way to put a number on the question of “how full to fill your glass” is to consider plan size growth. Plan size growth measures how the actual hours spent compare to the initial estimates. Let’s say, for example, that our team has a capacity of 200 available hours. The team commits to what it believes will be 190 hours, based on estimates. At the end of the Sprint, the team calculates that those stories contained 240 actual hours’ worth of work, resulting in a plan size growth of 20%.

A team that finds this discrepancy should spend some time during the retrospective investigating the reasons:

• Are too many tasks being discovered during execution that were not identified during planning?
• Is the team underestimating its tasks based on its current skill set?
• Did the team overestimate its capacity?
• And so on.

The team should also consider its plan size growth during the next Sprint Planning Meeting when determining whether it can commit to a story. Going back to our example, if the team still estimates a capacity of 200 hours, the team should subtract 20% off the top to compensate for “expected” plan size growth based on historical data. In other words, for at least this Sprint, to prevent spills, when the team gets to 160 hours, it should declare itself at capacity.

Considering plan size growth is one way to quantify how full the Sprint should be. Realize, however, that the goal is not to exactly match capacity. Rather, it is to allow the team to feel confident in committing to an appropriate number of stories—a number that pushes the team without overburdening it. Plan size growth is just a way to determine approximately how full the next Sprint should be, if all other factors remain equal.

When all of the stories are estimated or all of the time is consumed by stories, go back to the Product Owner, and share the Sprint Backlog that the team has committed to deliver. The Sprint starts now—so get to work!

Common Problems

In my years consulting with teams to help them adopt Scrum, I’ve seen many of the same problems that prevent successful Sprint Planning. Although Sprint Planning seems straightforward, teams that are just getting started with Scrum tend to struggle. Many of these problems and their potential solutions are detailed in this section.

Scenario: The team cannot commit to all the stories the Product Owner has requested.

You should expect this to happen occasionally. As long as the team can back up the commitment with data from steps four and five earlier in this topic, the Product Owner should be satisfied. You’ll want to keep an eye out to make sure this failure to commit is not a result of over-padding or large tasks. The Scrum Master should challenge what seem to be overly conservative estimates to make sure they are accurate. The Product Owner should question any task that has a two-digit estimate. Any task that is estimated to take longer than two working days should be broken down into smaller tasks and re-estimated. This is true for all projects but is especially troubling for teams running one-week or two-week Sprints.

Scenario: The Product Owner does not come prepared.

One Scrum value is respect. It is disrespectful to come to a meeting unprepared. So what’s a team to do if the Product Owner shows up without the information the team needs? Although one option is to postpone the meeting until the Product Owner is ready, doing so only encourages the same behavior—avoid it. Another option is to cancel the Sprint. Although this can work, it is extreme.

I find the best solution to be two-fold. First, the product backlog should be in some sort of priority order, so if the Product Owner doesn’t have a particular set of stories, the team and Product Owner can just discuss the stories in priority order until they reach a point where they believe they will be at or beyond capacity. The team can then decide on the exact commitment during Part 2 of the meeting, as usual.

After the meeting, the Scrum Master should work to understand why the Product Owner wasn’t prepared. If the problem was a lack of engagement, the Scrum Master can educate the Product Owner on the importance of coming to the meeting prepared with a set of stories. If, on the other hand, the problem was that the Product Owner was unable to prepare, perhaps because the team failed to help with grooming, the Scrum Master should help to solve those problems as well.

Scenario: Sprint Planning Part 1 exceeds its timebox.

Another value is focus. If Part 1 of the meeting is running over, it is symptomatic of a lack of focus. Sometimes the Product Owner is unfocused because of lack of preparation, prioritization, or trying to explain too many stories. Other times, the lack of focus might come from the team derailing the “what” conversations with specifics of “how.”

The Scrum Master should help move things along by insisting that the Product Owner table any stories that cannot be fully explained and that the team keep detailed implementation discussions out of Part 1. One simple fix for unfocused discussion is to use a stopwatch or timer.

Scenario: Sprint Planning Part 2 exceeds its timebox.

Again, focus. If you have a team that talks a lot, sometimes having the discipline to limit discussions is all that is needed to bring the meeting back in line. Bring an egg timer and keep the conversations to a minute or two between task estimates. The goal is accuracy, not 100% precision.

Other times, a lack of focus during Part 2 is symptomatic of a lack of product backlog grooming during Sprint execution. Grooming is a time when the team can look at future stories and work with the Product Owner to add stories or spikes for pinning down design directions or addressing architecture questions. Without regular product backlog grooming, Sprint Backlog planning becomes unwieldy and painful.

Scenario: The Product Owner is not available.

If the Product Owner can’t attend the meeting for any reason and has not appointed a proxy, act as if the Product Owner came to the meeting unprepared. Work through the top items and commit to them the best you can. You might be tempted to change the time of the meeting to accommodate the Product Owner’s schedule. Don’t. Shifting the time of the meeting accommodates the need of one at the expense of the many. It’s not worth it.

Scenario: The team doesn’t have the acceptance criteria it needs.

I always advise teams to ask the Product Owner during Part 1, “What’s the acceptance criteria for this?” or “What do we need to do to get you to accept the work?” If this is missing in Part 2, when the team is determining the tasks, the team will have no idea how to get the story to close. If the team has to guess, based on what it heard in Part 1, the team runs the risk of the Product Owner deciding at the end of the Sprint that the story is not finished. Ask for acceptance criteria from the start for each story. Scrum Masters—coach your Product Owners to provide this data.

Scenario: The Product Owner doesn’t know what done means.

Just like the team wants acceptance criteria, the Product Owner deserves an up-to-date description of what the team means by “the story is done.” This done list should be prominently posted, up to date, and available to the Product Owner at all times. An out-of-date done list makes it difficult to plan because there is no common understanding of what done will look like. Be sure that updating the done list is a part of every Sprint review or retrospective.

Scenario: The Scrum Master or Product Owner is estimating/influencing the team’s estimates/work.

The Product Owner is welcome in Part 2 of the meeting, but the Product Owner’s role in Part 2 should be limited to clarifying a requirement or addressing a specific question. The Product Owner should never interfere with the team’s discussion of how to implement a story and has no say in a task’s estimate. The Product Owner needs to trust the team to do the work.

If the Product Owner is acting outside of these guidelines, the Scrum Master should coach the Product Owner to a more appropriate role. If the Product Owner refuses to accept a more passive role, the Scrum Master has the authority to ask the Product Owner to leave.

Sprint Planning does not need to be challenging. It is often fun and a time for the entire Scrum team to build camaraderie by working together to answer the question of “What can we commit to?” Remember, if you find that your meetings run long, root cause issues are probably causing this. If you are the Scrum Master, keep the meeting focused by ensuring that the Product Owner and the team groom the product backlog. Help the Product Owner come prepared by having story acceptance criteria ready before the meeting. Finally, help keep the Product Owner and the team focused on the task at hand—determining what they can commit to for the Sprint.