A subtle misconception about Velocity
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.
Another quote:
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.
André Dhondt
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!
May 26th, 2012 at 19:25
I agree that an unstable velocity is an indicator of some problems in how we write software, or estimate, or manage the iteration.
I don’t agree that maximising or stabilising velocity are an objective.
Velocity is only a value that we “read” to learn something about what we delivered.
Adding a variable/artificial slack to the iteration velocity can also hide other types of problems.
Deliver “value” and “maintaining quality” is the objective.
Aiming to a certain velocity number is always wrong.
When you mention “reducing technical debt, to clean the system, to improve the tests, to study, to perform technical improvements” …all of these activities should be done daily irrespective of the fact that in this iteration we have some slack left or not.
I’ve seen many times velocity used as a tool to keep high, low or steady the business pressure on the team but they are all misuses.
Velocity is only a tool to “learn” what we’ve done this iteration and what we can roughly expect the next one if the context remains the same.
Velocity is for capacity calibration, is not a productivity measure, is not a team pressure valve or gauge.
You may be interested in this:
http://jimhighsmith.com/2011/11/02/velocity-is-killing-agility/
Ilias
May 26th, 2012 at 23:41
I agree with both of you … in my way:
I think that velocity has to remain a private tool for the team. None outside the team has to know it.
The only measure for the team work has to be the delivered software, measured by the business value.
May 27th, 2012 at 12:44
@Ilias:
I agree that the real objectives are to deliver value, and to always improve. Other measures are just tools to help us reach that goal, and they may only be temporary tools that we throw away when they are no longer useful.
My point here is that when you have a team that is not yet to the point of reliably delivering value, it’s not a good idea to strive to deliver as many completed stories as possible. Maybe this is obvious to more experienced agilists, but it was not obvious to me :-)
It’s true that cleaning up the code and paying down technical debt are activities that *should* be done continuously. But it’s virtually guaranteed that a beginning team will *not* do this to the level that is actually required. It’s surprising how much cleanup the code *really* needs :-) So one way to make sure that the team takes the time to really clean up, is to make sure that they have spare time in their iteration. This at least is my current understanding.
I’m not sure what you mean when you say that adding slack may lead to hide problems; can you elaborate on that?
@Ilias and @roberto: I didn’t say that explicitly, but I completely agree that velocity is a measure that is not reported outside the team. This does not prevent pressure to deliver faster, though. Most teams deliver more slowly than is desired; I think we can all agree on this? It’s only natural that the developers themselves will try to do one more story, as long as they believe that the code is refactored enough. It’s easy for them to be wrong on this :-)
May 27th, 2012 at 12:55
@ilias: I think Jim Highsmith agrees with me :-) Velocity should be used to calibrate what we can deliver. Slack is needed so that the team can invest in the development engine, as Jim says. The PO is not allowed to tell the team how to use their slack time, so he is not empowered to fix all priorities.
May 27th, 2012 at 20:36
“I’m not sure what you mean when you say that adding slack may lead to hide problems; can you elaborate on that?”
Are you looking at how much of this slack time are you “actually” doing?
Sorry, I may make a lot of wrong assumptions for this example:
Two iteration ago you velocity was 42 and you had enough time for those “extra activities” that fit in you slack.
Last iteration a couple of stories bumped into issues and took longer, no time for “extra activities” but your velocity is still 42.
Team during the retrospective looks at its velocity and thinks that this has been another good iteration: 42 same as last time… and maybe also the PO looks at the velocity and thinks that everything is great…
You missed a chance to see at your lower velocity and start a conversation on what didn’t went well.
Slack is not “optional” and left for the end of the iteration.
Ilias
May 27th, 2012 at 20:52
And obviously any solution depends on the context :)
For a team that is forming and on the path of reaching maturity to improve continuously nothing is obvious. Also finding time and courage for removing debt and invest in improvement needs incremental steps: I see that adding a slack can be a first good step.
May 29th, 2012 at 12:14
Having a stable velocity, and with that having hopefully the ability to do make long term plans are concepts based on a reasonable model about an “economy of software development” that is just an abstractiom, very useful if used as a thinking and communication tool, but very bad if some occasions.
We’d rather use it to understand the importance of not getting drawn into a kind of “quick fix” trap, for example.
Unfortunately in communicating that we are going to measure the velocity and failing in communicating the underline reason (justified by such “model”), is exactly the right way to fall into a quick fix trap, creating conflicts, backfiring all our good intention (and we know that the road to hell is paved with good intentions).
In that case, better not using any velocity metrics explicitly, and just coach the teams to write clean code.
Make sure doing relative estimates (if you do them, otherwise be sure the stories are small enough) and make sure that also the P.O. is able to prioritize the backlog items, by optimizing by “max value, min cost” (that means that the P.O. should have an idea of the business value of any backlog item).
In writing bad code we don’t learn anything, have stress, and the accidental complexity created will trashes any estimate slowing down everything.
In striving for writing clean code we can think better, learn better and hopefully have a basecode that will minimize the possibility of trashing the estimates (it doesn’t mean that we can formally prove it, or that there is a science behind that yet, but it doesn’t really matter. It’s craftsmanship).
June 3rd, 2012 at 12:30
While working on a recent project alone, I did not have a stable velocity as the main goal, but it came out as a result. The psychological effect was good (“slow and steady wins the race”) as it validated that I was at least cleaning up *enough*; what I am not sure is if I was cleaning up *too much*.
June 3rd, 2012 at 15:11
Giorgio: in my opinion, you know you are refactoring too much when the system starts becoming more complicated !!