Velocity Is Not A Performance Metric

Somewhere in your organisation there is a slide with team velocities on it. The teams are in rows, the sprints are in columns, and the numbers are coloured green where they went up and red where they went down. Somebody built it because somebody asked for it, and neither of them is entirely comfortable with it, but it has been in the pack for so long that removing it would require an explanation.

This article is the explanation.

Velocity is a forecasting aid. It was designed for a single team to use on itself, over a short horizon, to answer one narrow question: roughly how much should we take on this sprint? It has no meaning outside that team, no meaning outside that horizon, and no validity whatsoever as a measure of performance, productivity or value. Every property that makes it useful for its intended purpose makes it useless for the purpose it is usually put to.

The problem is not that people are misusing a good metric. It is that velocity, reported upward, actively creates the dysfunctions it appears to measure. It is one of the cleanest illustrations of Goodhart's Law available in delivery management: the moment velocity becomes a target, it stops describing anything at all.

What story points were actually for

Story points emerged from a specific and sensible problem. Estimating in hours invites two failures. It invites comparison between individuals, because an hour is an hour and a task that took one person four hours and another twelve becomes a judgement about the two people. And it invites false precision, because hours feel objective and therefore get committed to, tracked against, and used as evidence.

Points were deliberately constructed to resist both. They are relative, not absolute: this item is about twice that one. They are unitless, so they cannot be converted into money or headcount without an intermediate step that someone has to defend. They are assigned by the team collectively, so they encode the team's shared understanding rather than an individual's capability. And crucially, their scale is arbitrary — a five means nothing except in relation to the threes and eights on the same team's board.

That arbitrariness is the design. It is what makes points safe to be wrong about, which is what allows estimation to be quick and conversational rather than defensive. The value of a planning poker session was never the number; it was the argument that produced it, in which somebody says "wait, why do you think that's a three?" and a misunderstanding about scope gets caught before anyone writes code.

Velocity is simply the sum of points completed per sprint. It works as a forecasting aid for the same reason it is arbitrary: within one team, with a stable composition and a stable interpretation of the scale, the sum is roughly repeatable. That is all it needs to be.

Why it cannot be compared across teams

This is the part that gets nodded at and then ignored, so it is worth stating mechanically rather than as a principle.

Team A calibrated its scale in 2023 against a piece of work nobody currently on the team remembers. Team B calibrated theirs against something else entirely, and then had two members leave and three join, each of whom brought their intuitions from previous teams. Team C had a well-intentioned Scrum Master who suggested that a one should be "about a day", which quietly reintroduced hours and shifted the whole scale.

There is no exchange rate between these. A thirteen on one board and a thirteen on another are not the same quantity in different currencies; they are different quantities with the same name. Summing them produces a number with no referent, and comparing them produces a ranking of estimation conventions.

It is worse than merely meaningless, because it is systematically biased in a predictable direction. A team that splits its work well will have more, smaller items, and will tend to have a lower total point count for the same output than a team that leaves work in large lumps. A team that includes technical work, defects and support in its estimates will look slower than an identical team that only points feature work. A team working in an unfamiliar legacy codebase will inflate its estimates to reflect uncertainty, which is correct behaviour, and will then appear to be producing more than a team doing comparable work in a codebase it knows. Every one of these biases rewards the behaviour you would rather discourage.

The four pathologies

When velocity is reported upward and interpreted as performance, four things happen. They happen in roughly this order, and they happen without anyone deciding to be dishonest.

Inflation. Estimates drift upward. Nobody plans this. It emerges because there is no cost to estimating high and a visible cost to estimating low, and because after the first sprint where velocity dropped and someone asked about it, the team learned something. Point inflation is the delivery equivalent of a currency debasing: the number rises steadily, the underlying output does not, and everyone involved can see it happening while remaining individually rational.

Gaming at the boundary. Work gets counted in whichever sprint makes the number look better. Items are declared done at ninety percent complete to land inside the sprint; items are held back to pad a weak sprint ahead. Partial credit appears. The sprint boundary stops being a cadence and starts being an accounting period, with all the behaviour that accounting periods produce at quarter end.

Quality erosion. This is the expensive one. Velocity counts completion, not durability. Under pressure to maintain the number, the things that get dropped are the invisible ones: test coverage, refactoring, documentation, the careful version of the fix rather than the quick one. The result is a metric that rises while the system it measures degrades, and the degradation surfaces two or three quarters later as unexplained slowness that gets attributed to the team rather than to the measurement regime that produced it. This is why velocity pressure and technical debt are so reliably found together.

Refusal to split. The most damaging and the least discussed. Splitting a large item into three smaller ones usually reduces the total point count, because the padding for uncertainty in the large item disappears once the work is understood. If velocity matters, splitting is penalised. So teams stop splitting, items stay large, batch size rises, flow time rises, feedback slows and failure diagnosis gets harder. A metric intended to help with planning ends up suppressing the single most valuable delivery practice available to the team.

What to report instead

The question behind the request for velocity is almost always legitimate. Somebody wants to know when things will be ready and whether the organisation is getting better. Both are answerable, just not by points.

Question being asked	Bad answer	Better answer
Are we getting faster?	Velocity trend	Flow time percentiles, trending
How much are we getting through?	Points per sprint	Throughput: items completed per week
When will this be done?	Points remaining ÷ velocity	Monte Carlo forecast from throughput history, stated as a probability
Are we spending capacity well?	Feature points delivered	Flow distribution: proportion of work by type
Are we delivering value?	Any of the above	Outcome measures for the product, separately owned
Is delivery healthy overall?	Velocity comparison	The four key metrics, as a set, as trends

Three properties make these better, and it is worth naming them because they generalise.

They are countable from systems of record rather than assigned by the people being measured. Nobody decides how many days elapsed.

They are comparable across teams without being a ranking, because a day is a day everywhere. You still should not rank teams on flow time — domains differ — but at least the units mean the same thing, so a cross-team aggregate is arithmetic rather than fiction.

They degrade gracefully under gaming. You can game throughput by splitting items smaller, which is a behaviour you wanted anyway. Compare that to gaming velocity by inflating estimates, which produces nothing.

The details of how to instrument all of these are in the flow metrics guide.

The case for dropping estimation entirely

Once you are forecasting from throughput, a reasonable question follows: what is the estimation for?

The honest answer is that a large part of it is for nothing. If your forecast comes from counting completed items and simulating forward, the point values were never an input. The team spent a recurring block of time each sprint producing a number that feeds a metric you have just stopped using.

The alternative is right-sizing. Instead of estimating each item on a scale, you ask a single yes-or-no question: is this small enough? Small enough usually means completable within a few days by whoever picks it up. If yes, it goes in the queue. If no, it gets split until the answer is yes, or explicitly flagged as requiring discovery before it can be sized at all.

This preserves everything valuable about estimation and discards the rest. You keep the conversation, which is where the shared understanding and the caught misunderstandings live. You keep the pressure toward splitting, and in fact you intensify it, because splitting is now the response to every item that fails the test rather than something that costs you points. You lose the number, which was arbitrary, and the ceremony, which was expensive.

Some caveats, because this is often oversold.

You still need coarse sizing for portfolio decisions. Deciding whether to fund something at all requires knowing whether it is a three-week or a nine-month undertaking. That is a different activity, done once, at a different altitude, and it does not require story points on every ticket.

Right-sizing works badly on genuinely novel work. If nobody knows whether something is small, the answer is a timeboxed spike, not an estimate. Be explicit that you are buying information rather than producing a forecast.

You need enough throughput history before you stop. Run both for a couple of months and compare the forecasts. In most teams the empirical forecast will be at least as accurate and considerably cheaper, and having that comparison in hand is what makes the conversation with stakeholders straightforward rather than ideological.

Some contexts require estimates contractually. Fixed-price arrangements and certain funding models genuinely demand a number up front. That is a commercial constraint, not a delivery practice, and it should be handled as one rather than pushed down into the team's weekly routine.

What to do on Monday

Find every place velocity currently appears in reporting above team level. There will be more than you expect. For each one, find out what decision it informs. Most will inform none, and can be removed without replacement.

For the ones that do inform something, work out which of the questions in the table above is really being asked, and produce that number instead. You will need throughput history; ninety days of completed item counts is enough to start.

Tell the team, explicitly, that velocity is no longer reported upward and that nobody is watching the number. Then watch what happens to estimates over the following month. The drift will tell you how much inflation had accumulated, which is a useful and slightly sobering measurement in its own right.

Run one sprint where you right-size instead of estimating: every item gets a yes or no on "small enough", and anything that fails gets split before it is pulled. Compare the planning time against a normal sprint, and compare the size distribution of what you actually delivered.

Then keep forecasting from throughput for a quarter alongside whatever the existing method is, and put the two accuracy records side by side. That comparison is the only argument that reliably persuades a stakeholder who has been given dates for twenty years, and it is much more effective than telling them that story points were never meant to be a performance metric — which is true, and which they have almost certainly heard before.