There are two general approaches to planning sprints: velocity-driven planning and commitment-driven planning. Over the next three posts, I will describe each approach, and make my case for the one I prefer.

Let’s begin with velocity-driven sprint planning because it’s the easiest to describe. Velocity-driven sprint planning is based on the premise that the amount of work a team will do in the coming sprint is roughly equal to what they’ve done in prior sprints. This is a very valid premise.

This does assume, of course, things such as a constant team size, the team is working on similar work from sprint to sprint, consistent sprint lengths, and so on. Each of these assumptions is generally valid and violations of the assumptions are easily identified—that is, when a sprint changes from 10 to nine working days as in the case of a holiday, the team knows this in advance.

The steps in velocity-driven sprint planning are as follows:

1. Determine the team’s historical average velocity.
2. Select a number of product backlog items equal to that velocity.

Some teams stop there. Others include the additional step of:

3. Identify the tasks involved in the selected user stories and see if it feels like the right amount of work.

And some teams will go even further and:

4. Estimate the tasks and see if the sum of the work is in line with past sprints.

Let’s look in more detail at each of these steps.

Step 1. Select the Team’s Average Velocity

The first step in velocity-driven sprint planning is determining the team’s average velocity. Some agile teams prefer to look only at their most recent velocity. Their logic is that the most recent sprint is the single best indicator of how much will be accomplished in the next sprint. While this is certainly valid, I prefer to look back over a longer period if the team has the data.

I prefer to take the average of the eight most recent sprints. I’ve found that to be fairly predictive of the future. I certainly wouldn’t take the average over the last 10 years. How fast a team was going during the Bush Administration is irrelevant to that team’s velocity today. But, similarly, if you have the data, I don’t think you should look back only one sprint.

Step 2: Select Product Backlog Items

Armed with an average velocity, team members select the top items from the product backlog. They grab items up to or equal to the average velocity.

At this point, velocity-driven planning in the strictest sense is finished. Rather than taking an hour or two per week of the sprint, sprint planning is done in a matter of seconds. As quickly as the team can add up to their average velocity, they’re done.

Step 3: Identify Tasks (Optional)

Most teams who favor velocity-driven sprint planning realize that planning a sprint in a few seconds is probably insufficient. And so many will add in this third step of identifying the tasks to be performed.

To do this, team members discuss each of the product backlog items that have been selected for the sprint and attempt to identify the key steps necessary in delivering each product backlog item. Teams can’t possibly think of everything so they instead make a good faith effort to think of all they can.

After having identified most of the tasks that will ultimately be necessary, team members look at the selected product backlog item and the tasks for each, and decide if the sprint seems full. They may conclude that the sprint is overfilled or insufficiently filled and add or drop product backlog items. At this point, some teams are done and they conclude sprint planning with a set of selected product backlog items and a list of the tasks to deliver them. Some teams proceed though to a final step:

Step 4: Estimate the Tasks (Optional)

With a nice list of tasks in front of them, some teams decide to go ahead and estimate those tasks in hours, as an aid in helping them decide if they’ve selected the right amount of work.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

I am the Product Owner of a web development team. I have been keeping statistics on the teams performance for over a year now and previously had the team's velocity pegged at ~35 story points. However, lately I'm challenged with velocity due to two events. First, the team underwent a change of developers so I'm now keeping new velocity stats based on the new team composition.The second event, and the one I really need guidance on is the inability to complete user stories within an assigned sprint. Sometimes the carryover is due to user stories that turnout to be more complex than originally estimated. Other times the team has taken on more story points than could be completed within the sprint.When user stories are not completed my Scrum Master wants to leave the uncompleted user story(s) in their orginal sprint with the original story points. Then make a copy of the user story in the next sprint with newly estimate story points. This is inflating the number of story points that are "completed" in a given sprint, and is inflating the team's average velocity. For uncompleted user stories I prefer to roll them over to the next sprint which reduces the total story points of the current sprint and reflect the work to be completed in the next sprint.Question - to accurately account for velocity how should the Scrum Master handle uncompleted user stories in a given sprint?

Posted by Kent on 2015-02-03 11:17:14

For me the questions will always be intertwined. For example, suppose it’s my wife’s birthday and I need to buy her a gift. Should I figure out “what” before I figure “how”? I overheard my wife one say she liked a particular Monet painting. So, there’s my what. I’ll buy her one of his paintings. How I just need to figure out *how* to afford a few million dollars and how to convince the Musee d’Orsay to sell me his Blue Water Lilies. No, instead I should think about what to get her and how to get it (afford it; actually buy it) at the same time.

Posted by mikewcohn on 2014-12-03 16:30:56

Hi Mike,Yes, certainly i agree what you say. I am also been thinking, how one can say "what they are doing ", without knowing "how to go about". In fact I was fully convinced after reading your article. but some say "forecast" in the sprint planning as per core scrum , should come from the team's feeling than estimating how much we can do through numbers. I strongly feel, some amount of past performance and current capacity should be known while deciding "what" part then "how" part makes more clear when we decide the tasks estimate(approximate estimate).

Posted by Niranjan on 2014-12-03 08:51:20

Hi Niranjan—

You’d need to ask someone who actually does sprint planning that way. I can’t imagine a meeting where I’m asked to figure out what I’m doing before I figure out how I’m doing it. When I wrote Agile Estimating and Planning, I looked around for teams doing that and couldn’t find *any*. I’m sure there are some now since it’s still talked about but I don’t get it. It’s certainly not how I work or think.

Posted by mikewcohn on 2014-12-02 23:10:21

Hi MIke,It is a great article. It adds lot of clarity to the "forecast " word used in core scrum.

I have some more queries.Core Scrum says Sprint Planning has two parts. Part 1 - What and Part 2- How.

Normally scrum teams make a forecast in Part 1 and agree on the sprint goal with PO, before they go to Part 2- How. As per your article, can i take , "Part 1-What part consists of Step 1,2" and " Sprint Planning part 2 -How " part consists of step 3, 4.

Please clarify.

Posted by Niranjan on 2014-12-02 12:19:02

Thanks, Thomas.

I agree with your observation that 4-5 sprints are needed. Sometimes you can start to have an idea after 3 but I sure like 4-5 a lot more.

Posted by mikewcohn on 2014-10-27 09:08:50

Awesome article!Mike is there a minimum number of sprints a team should have completed before be able to calculate the average velocity? From what I have observed around sprint 4-5 a teams average starts to flatten out.

Posted by Thomas Henson on 2014-10-27 08:39:36

Great point, Tom.

Never become a slave to the math. Always trust your judgment on these things—a ScrumMaster is there observing the team, the formulas aren’t. If you think being conservative would better reflect a true forecast of velocity, do that. Similarly, if past velocities were 5, 10, 15, 20, 25, 30, 35, 40, in that order, I’d be pretty inclined to discount the first few sprints and weigh the latter ones more heavily!

Posted by mikewcohn on 2014-10-26 14:45:02

In looking at Step 1: Select the Team's average velocity, if a team's velocity varies quite a bit in the previous 8-10 sprints can should we be conservative in setting the team's velocity? Or perhaps do we need to look at our estimates? Thanks Mike

Posted by Tom Henricksen on 2014-10-26 07:00:21

Our team goes one step further, during sprint planning we review the stories so each developer verifies their understanding again since some stories could have been estimated a month or more ago. Then each developer takes stories until they feel their sprint plate is full. It is usually a mix of sizes and priorities. If someone finishes their stories before the end of the sprint they will ask others if they can take one of their stories. In the end the team understands that they have collectively committed to everything each developer has taken. This helps the team self-organize and keep each other from over or under committing.

Posted by Donna Alexander on 2014-10-24 11:16:05

Hi Dieter—

I’ve looked for evidence that teams who slightly overcommit outperform teams who slightly undercommit (or vice versa). I have not found any evidence in either direction. I believe it is a very “personal” (team) thing. Speaking of just myself, if I take on more than I have reason to believe I can finish, the extra feels like a crushing weight. Other teams can identify it as a “stretch goal” and not be bothered by it at all—it’s there if they have time, but no big deal if not.

Posted by mikewcohn on 2014-10-23 07:29:46

Our team's average velocity over the past 6 sprints has been 16. Last two sprints were 13. The product owner (me) offers items from the backlog which have in best case been groomed but importance will always prevail over being groomed or not. This means some part of the planning is devoted to grooming, which is not ideal but not always avoidable.

This team tends to overcommit, so I will remind them of the average velocity, at which point we or I decide which part is above the commitment bar (8-1-3-2-2). The rest (5-1) is under the bar. This time it looks like we'll make the 16 at least.

I've worked with other teams who prefer to undercommit because a crowded sprint discourages them and they can report later on the extras taken on, which gives them good feeling and image. This team seems emotionally unaffected with not reaching (uncommitted) sprint goals. They strive to reach the commitment but prefer to have a buffer of work. Usually reality comes haunting them and reaching the commitment alone is already hard (mostly due to circumstances and dependencies, not lack of zeal).

I think either approach is fine but to me overcommitting is a sign of a confident team and undercommitting is a sign of an insecure team, either in its own abilities or in the reward/punishment by the company. I will always adapt to the team's spirit first. Structural undercommitment may foster confidence. There is a risk of sloth, which the general tendency of good faith in agile literature will not retain, but in my experience is also there.

Looking forward to next post to see where you draw the difference. My guess is that your "commitment driven planning" is about foreign commitments and that you prefer velocity driven planning, which I think coincides with team commitment driven planning.

Posted by Knotwilg on 2014-10-23 07:04:24

Thanks, Justin. Yes, in velocity-driven sprint planning, the stories would already have been estimated in story points.

Posted by mikewcohn on 2014-10-22 18:29:28

Great article Mike.Re: 2. Select a number of product backlog items equal to that velocity.- Are the product backlog items already sized in story points; and compared with the velocity thats also been captured in story points?Thanks.