Two months ago I re-started a freelance career. Now I have a new coaching engagement that I’m very happy about. One interesting thing that I learned in the past few weeks is that I had a fundamental misconception about the idea of velocity. I think that this misconception is common, so I will tell you about it.
You know what velocity is: it’s a very important number that measures how much a team has accomplished in the past iterations. When an iteration is finished, you add up the estimates of all the user stories that are done-done. That is your velocity.
There is a common misconception about velocity, that it can be used to compare teams or to reward/punish the team. This is a well-known and well-documented error, because doing so will push the team to game the metric and destroy its usefulness.
But it is not that error I want to talk about; it’s a more subtle one. You know, ever since I learned about XP, I always thought that the goal of an XP team is to maximize velocity. That is, to deliver as much as possible, while keeping the system clean and well tested and so on.
This is an error. You don’t want to maximize velocity. Your goal is to stabilize velocity. What you want is to deliver about the same velocity in each iteration; and the way to obtain this is to add slack; make sure that if the estimates are correct, you will end the iteration with ample extra time. The team will *not* use the extra time to deliver one more story; they will use it to reduce technical debt, to clean the system, to improve the tests, to study, to perform technical improvements, and so on.
This is a very counter-intuitive thing, yet I now understand that if you don’t use slack to keep the velocity stable, it’s very difficult to achieve the goal of keeping the cost of change down. Thanks to James Shore for the video of his presentation We Deliver Business Value at the NDC2011 conference. The concept is also well explained in Shore and Warden’s book.
The Product Owners look at slack as a way to evaluate whether the team is overloaded–and seek to reduce velocity until we hit slack consistently. Otherwise, we fear we’ll be paying for code debt, bug fixes, and reduced innovation that the team can’t really see until they come up for air.
Also, a fundamental principle in Lean is that before you try to optimize you should stabilize: reduce variation in the output.
Now you know it!