Velocity is not a Team Performance Metric!
Recently I’ve been following an interesting thread on the XP yahoo mailing list asking the question… should we measure individual velocity?
The general response seems to be “NOT AT ALL!!!”, but I won’t repeat the discussion there when you can read it yourself, but I thought I’d pick out an interesting point from the thread that was mentioned and expand on it.
Velocity is not a team performance metric, but a planning tool that
helps the team realize how much they can commit to a given iteration.
This seems to be a general point of confusion that always seems to come up and definitely bears repeating. From my point of view, velocity is basically a way of saying “the team completed on average x number of units per iteration the last y iterations, so the customers can expect x units will be completed next week. So, dear customer, with x units to spend this iteration, what features would you like to see implemented?”
Using velocity as performance metric is dangerous imho because it assumes that a team is either doing poorly due to a decline in velocity, or that a high velocity means a team is superb and probably deserves a hefty bonus. Rubbish.
Measuring individual velocity would be a disaster of epic proportions imho… it would go against the grain of teamwork first of all, since why would individuals or pairs feel motivated to ensure that the overall team does well velocitywise? Likewise, it would be a poor metric. If pair A completes 10 1 unit cards that were freakin easy (lets say each card was doable in a session or less) and pair B completes one 3 unit card and one 1 unit card that winds up taking awhile due to external factors, you can’t really sit there and say “pair A is a lot more productive than pair B, since pair B only completed 4 units. Maybe we need to do something to get them moving!”
Velocity is not about performance… it’s about providing your customer with a close to accurate amount of “points” they can spend on features this iteration. Remember that.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
December 30th, 2007 at 8:48 pm
I agree completely. Velocity is a terrible metric for actual performance because it covers up actual performance. For instance, suppose a team has some breakthrough in development efficiency. For one iteration their velocity spikes, but the next time they estimate similar tasks they of course estimate them much lower because they know that these tasks are going to much less time than they did previously. Meanwhile their average velocity goes up from the spike, so the next iteration’s expected velocity is higher. They probably won’t meet this new velocity, so the average will come back down and everything will be more predictable again in a couple of iterations.
When the expected velocity stabilizes at a level equal to the level before the breakthrough, is the team producing the same development throughput as before? No!!! They are producing more! They had a breakthrough in development efficiency that they will continue to benefit from forever so long as their problem domain remains the same. However, velocity would seem to indicate that they are not producing any more than they had before the velocity spike and subsequent unpredictability.
From a business person’s perspective all that is noticed is the unpredictability. Velocity alone provides no way for them to know that their development team is producing any more than they had before. Thus, an occasion that should be celebrated, the efficiency breakthrough, turns into a cause for tension between business and development.