Velocity, in the Agile sense of the word, is a measurement of the number of user stories completed in a period of time. I’m very new to the concept, but I’m immediately skeptical for the following reasons:

• Technical debt is nowhere represented in the velocity model. In fact, optimizing for short-term velocity will tend to accumulate technical debt. The incentive here is toward shortsighted implementations that will satisfy the acceptance criteria, with less care taken to accommodate future requirements.

• Because velocity can be so misleading, it is often abstracted away from stakeholders. The measurement also tends to be too technical to be exposed to corporate officers. Given that velocity will tend to be used internally within a development group, why not express more of the complexity and uncertainty of the development process?

I’m reminded of airspeed and altitude. Aircraft can trade airspeed for altitude, and vice versa. Technical debt is a bit like altitude. Technical debt can be taken on to increase velocity, just as aircraft can dive to gain airspeed. When velocity is reduced due to refactoring and debugging, is is analogous to an aircraft “bleeding speed” by climbing. The optimal condition is low technical debt and high velocity, just as an aircraft at cruising altitude and airspeed is at its most efficient. A project high in technical debt and low in velocity is in trouble, like an aircraft flying low and slow is at risk of stalling and crashing.

The metaphor is imperfect, but I still think a compound measurement or multiple independent measurements would be strictly superior to the current notion of velocity.