Sprint Planning, Velocity, and Reality

Looking at the following graph, how many story points should the team pull into their next iteration? Click the image to make it bigger.

There are several schools of thought on this. Mike Cohn refers to 2 different types of iteration planning: Commitment based planning and Velocity based planning.

Velocity Based Iteration Planning

Velocity based planning says that we will use the numbers in the chart above to derive how many points are to be “pulled” into the next iteration. You can use the average over time, the number of story points done in the last sprint, or some other facet of the above graph, but in any case you are using velocity of the team to feed the next set of work.

The careful reader should note here that this is in fact a push of work into the iteration, not a pull. This technique puts the control of commitment in the hands of the chart instead of in the hands of the team. One could even argue this is a disincentive for increasing velocity.

Commitment Based Iteration Planning

Commitment based planning says the team does this:

1. Team answers, “Can we commit to any more work this iteration?”
1. If no, iteration planning complete.
2. Pull the next item from the top of the backlog.
3. Team answers, “Can we commit to this work in this iteration?”
1. If yes
1. Work item comes into this iteration
2. Go to top step #1.
2. If no
1. Work item goes back onto the backlog
2. Go to top step #1.

Velocity vs. Commitment

Here are some qualities of each type of iteration planning technique.

So, which is better? Commitment based tends to allow changes in velocity without penalty while accounting for current conditions. For example, what if Joe is on vacation next week? Does the team have a feel for the impact of Joe’s absence? You bet they do!

Does the velocity trend line know about Joe’s absence? Probably not.

You could mitigate this by putting Joe’s vacation into the iteration backlog as a cost of team hours thereby making your velocity look steady. In my opinion, this is gaming the numbers. Yes, you can do it. Does it reflect reality? Not really.

I vote for commitment based iteration planning every time. I believe it provides a more genuine model for reflecting probable outcome of the iteration than basing the workload on past performance.