Agile Otter Blog

In the last installment , we talked about reasons that velocity goes up without any more accomplishment by the team. This is a disturbing occurrence to many managers who want to use velocity as a measure of productivity, and their insistence on treating low velocity as a productivity measure. We'll pick up the conversation from there. A: I don't  like  the "estimating in larger numbers" explanation. What is an alternative explanation? B: Perhaps they've developed skills, knowledge, and/or techniques that make it easier to get more work done. There are a few ways of measuring efficiency. One of the least useful is output over time. If one team of people produce more in a week than another, isn't the one more efficient? It's not possible to say. They may put out a disproportionate amount of effort in order to get a higher yield. That could be arguably more productive  but it is not more efficient . If it's harder to get more work done, then yo...

The term velocity is very well-chosen. It means speed in a certain direction, with the intention that it refers to the teams rate of travel toward a product release.  I have suggested that velocity is just capacity and my intention was good and maybe even right in many ways. Velocity is the practical measure of our capacity being applied toward the completion of a release. The term still stands superior to my older suggestion. Lets start with the definition that velocity is the speed of progress in a given direction. The direction part gets missed. People (including my slightly younger self) want to do things like track bugs (" failure demand ") as velocity. It might be good to see how much capacity is being lost to failure demand, but it is not velocity toward the same goal, not really.  We don't want to know that the team is busy, we want to see when the project will be done. So we do not count bugs toward velocity. We want to see quality problems drive velocity...