Stop Calling It Velocity

If I could remove one metric from engineering organisations, it would be velocity.

Not because measurement is bad. Not because throughput doesn't matter. But because velocity - story points per sprint - has become one of the most reliably misleading metrics in the industry. It measures something real, but it is not the thing most organisations think it is measuring.

---

What Velocity Actually Measures

Velocity measures how many story points a team completes in a sprint. Story points are a relative estimate of effort or complexity. They are a planning tool - designed to help teams answer "how much can we take on this sprint?" - not a performance measure.

This distinction matters enormously. A story point is not a unit of value. It is a unit of estimated effort. A team that completes 80 points has not necessarily delivered more value than a team that completed 40. They may have worked on bigger things, or more complex things, or things that required more rework. Or they may have learned to estimate higher.

The moment velocity becomes a target - and it always does, once it appears on a dashboard visible to leadership - it ceases to be a planning tool and becomes a performance anxiety driver.

---

The Perverse Incentive

Teams respond to incentives. It's not cynical, it's human.

When velocity is tracked, compared across teams, or used to justify headcount, teams learn to manage the number. Estimates drift upward. "Just in case" points appear. Stories are split not at natural boundaries but at sprint boundaries. Acceptance criteria are interpreted favourably. The number goes up.

This is not the teams being dishonest. This is the teams responding rationally to a badly designed measurement system. The problem is the metric, not the people.

And here is the truly damaging part: high velocity can coexist with low value delivery. A team completing 80 points of features that nobody uses is less effective than a team completing 40 points of capabilities that measurably improve customer outcomes. Velocity cannot distinguish between these cases. It cannot tell you whether what shipped mattered.

---

What to Measure Instead

There are better proxies for the things organisations actually care about:

Cycle time - how long does it take from "work starts" to "work is in production"? This is a genuine flow measure. It reflects the efficiency of your development process without the estimation distortion of story points. Shorter cycle times, consistently, are a reliable indicator of system health.

Lead time for change - the DORA metric. From code committed to running in production. This measures pipeline capability and release friction.

Deployment frequency - how often do you release? More frequent deployments mean smaller batches, lower risk, faster feedback. This is a structural indicator of delivery health.

Throughput - how many items complete per week or sprint? Note: items, not points. Deliberately unweighted. This removes the estimation game while still tracking whether work is finishing.

Outcome metrics - the hardest to instrument but the most important. Did the thing you shipped produce the customer behaviour change you intended? Did conversion improve? Did the error rate fall? Did the customer satisfaction score move? These are the measures that answer whether velocity was spent on the right things.

---

The BVSSH View

Value in the BVSSH framework is explicit: it's not what you ship, it's what the customer receives and what the business gains. An organisation fixated on velocity has confused the mechanism of delivery with the purpose of delivery.

The best teams I have worked with have largely abandoned velocity as a progress indicator. They track cycle time to understand their flow. They track deployment frequency to understand their pipeline health. They track outcome metrics to understand whether their work mattered. They use sprint planning to allocate capacity - and they use relative estimation for that purpose and nothing else.

When leadership stops asking "what's the velocity?" and starts asking "what customer problem did we solve this sprint, and how do we know?" - the entire conversation changes. Teams think differently. Prioritisation changes. The signal is better.

---

The Transition Is Uncomfortable

Leaders who have used velocity for years often resist this shift. It feels like losing a measure they understand. The argument "at least velocity is consistent" - while technically flawed (it's consistent within a team, wildly inconsistent across teams) - has emotional force.

My response: consistency of a bad measure does not make it a good measure. A thermometer that consistently reads five degrees too high is not useful just because it's consistent.

The transition to better metrics takes time. Organisations need to instrument cycle time, build confidence in deployment frequency as a health indicator, and develop the discipline to tie work to outcomes. None of this is immediate.

But the organisations that have made this shift are making better decisions, building better products, and have engineering teams that feel accountable for outcomes rather than points.

That's the right direction. Stop optimising for velocity. Start optimising for value.