Is velocity a useful metric? Our verdict

Yes inside the team, harmful outside it. Velocity is a forecasting input the team steers by; the moment it becomes a target or a cross-team comparison it inflates and stops meaning anything. DORA left it out of the delivery metrics on purpose.

Yes inside the team, harmful outside it. Velocity is a forecasting input the team steers by; the moment it becomes a target or a cross-team comparison, it inflates and stops meaning anything. DORA left it out of the delivery metrics on purpose.

Almost everyone in the discourse agrees velocity should never leave the team — and almost every organization lets it leave anyway. That gap is the whole argument. The metric is genuinely useful for one job and reliably destructive for the others, so the verdict has to be split.

The case that velocity is useful

Used inside the team, velocity does real work. It lets you forecast: divide the remaining scope by the team’s recent average and you have a rough number of sprints to ship. It lets you size a realistic sprint: pick stories until they sum to roughly eighty to ninety percent of the recent average, leaving room for the unplanned. And it flags real change — a thirty-percent drop is a signal worth a conversation, not an accusation.

The management wish behind velocity-as-a-metric is also legitimate, and worth stating fairly. Leaders are accountable for delivery and want visibility into it. “If we can’t measure the team somehow, how do we know it’s delivering?” is a reasonable question, not a villain’s line. The problem isn’t the wish. It’s that velocity is the wrong instrument for it.

Velocity over six sprints with two outliers pulling the average above the sustainable rate 0 30 60 points avg 35 actual 29 s1 s2 s3 s4 s5 s6 easy sprint carry-over plan to the teal line, not the orange one
Two easy sprints pull the average above the team’s sustainable rate. Velocity is useful for planning to the typical sprint — and misleading the instant it becomes a number to push upward.

The case that velocity is a trap

Point velocity outward and it breaks in predictable ways. Set it as a target — “increase velocity twenty percent this quarter” — and the team obliges, by sizing the same work bigger rather than doing more of it. Turn a couple of threes into fives and the number climbs for no real increase in output. This is Goodhart’s law running on a two-week cycle, and it isn’t a hypothetical: even Mike Cohn, the leading advocate for story points, concedes that the slightest indication velocities will be compared produces gradual but consistent point inflation.

Cross-team comparison is worse, because it looks rigorous while being meaningless. Two teams sizing the same backlog produce different numbers because they calibrate against different reference stories — that’s the entire point of relative estimation. Averaging or ranking them corrupts both teams’ calibration to feed a dashboard. The tell that an org has this wrong is when someone senior has to personally shield their teams from velocity-as-a-KPI — a fix that works exactly as long as that person stays in the role.

Where we would change our mind

We would keep velocity without reservation for any team that uses it only to forecast and plan, and never lets it leave the room. Used that way it isn’t a trap at all — it’s just arithmetic the team does for itself.

We would drop it entirely in two cases. First, if the work is uniform enough that counting stories forecasts as well as summing points — then velocity is overhead, and throughput is simpler and harder to game. Second, if the organization can’t stop itself weaponising the number. When the ratchet is culturally locked in and no individual can hold it back, the honest move is to stop producing the number that is being abused and switch to flow metrics that are not.

The practical take

What leadership should watch Deployfrequency Lead timefor changes Change-failrate Time torestore DORA’s four keys — comparable, hard to game team boundary Velocity a planning input the team steers by not a KPI Send outcomes up; keep velocity in the room.
Give leadership the four keys — comparable across teams and hard to game — and keep velocity inside the team as a planning input, never a number pushed upward.
  • Velocity measures pace, not productivity. Say it out loud in the room the first time someone reads it as an output metric.
  • Never compare teams, never set it as a target, never convert it to expected hours per developer. Each is the same mistake wearing a different hat.
  • Report outcomes upward, not point counts. DORA’s four keys — deployment frequency, lead time for changes, change-failure rate, time to restore — measure delivery without inviting gaming and, unlike points, mean the same thing across teams. That’s the metric set leadership actually wants.
  • Don’t re-point the backlog when the team speeds up. The stories didn’t shrink — the team got faster, and the velocity number will rise on its own. Re-pointing to keep velocity flat is the ratchet running in reverse, and it wrecks the forecast the same way.

Velocity is for the team to steer by, not for managers to grade with. Keep it in the room and it’s one of the more useful numbers in agile. Let it out, and it becomes the cleanest example of a Power failure mode there is.

Frequently asked questions

Is velocity a productivity metric?

No. Velocity measures pace, not productivity — how many story points a specific team completes per sprint at its own calibration. It cannot tell you whether the work was valuable, and it was never designed to. DORA’s research deliberately excludes velocity from its delivery metrics for exactly this reason.

Can you compare velocity across teams?

No. Two teams sizing the same work produce different velocity numbers because they use different reference stories — that is the whole point of relative estimation. Comparing them is like comparing two thermometers with different zero points. Mike Cohn, who argues for story points, concedes that the slightest hint velocities will be compared produces consistent point inflation.

What should we report to management instead of velocity?

Report outcomes, not point counts. DORA’s four keys — deployment frequency, lead time for changes, change-failure rate and time to restore service — measure delivery in ways that do not invite gaming and are comparable across teams. Velocity stays inside the team as a planning input; the four keys are what leadership should actually watch.