Comments on: Velocity is not a Team Performance Metric! http://blog.james-carr.org/2007/12/28/velocity-is-not-a-team-performance-metric/ Rants and Musings of an Agile Developer Sat, 22 Nov 2008 06:50:06 +0000 http://wordpress.org/?v=2.6.1 By: Steve Asher http://blog.james-carr.org/2007/12/28/velocity-is-not-a-team-performance-metric/#comment-43844 Steve Asher Mon, 31 Dec 2007 00:48:25 +0000 http://blog.james-carr.org/2007/12/28/velocity-is-not-a-team-performance-metric/#comment-43844 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. 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.

]]>