Why Velocity Is a Lousy Measure of Productivity

Velocity is one of the most misused numbers in agile. It was designed as a sprint planning input, but it regularly gets repurposed as a productivity score - and that's where the problems start.

What velocity actually measures

Velocity measures how many story points a team completes in a sprint. Since story points are relative and team-specific, this number is only meaningful compared to that same team's own history. It cannot be compared across teams.

Why optimizing velocity backfires

When managers treat velocity as a productivity score, teams respond rationally: they inflate estimates. A 3 becomes a 5. A 5 becomes an 8. Velocity climbs, output doesn't. The number looks better; nothing else does.

Velocity hides quality trade-offs

A team can increase velocity by cutting corners on testing, skipping documentation, or building shortcuts that create future technical debt. Velocity has no memory. It doesn't measure the cost of decisions made in previous sprints.

What to use instead

If you're trying to understand team output, look at:

• Cycle time: how long it takes a story to go from started to done
• Throughput: number of items completed per sprint, regardless of size
• Escaped defects: bugs found after a story was marked complete
• Sprint goal hit rate: did the team achieve what it set out to do?

These metrics are harder to game and more directly tied to the things that matter.

Velocity still has a job

Velocity is useful as input to sprint planning: if a team has completed an average of 32 points over the last four sprints, that's a reasonable basis for committing to roughly 30 in the next one. That's the job it was designed for.

Use velocity as a planning tool. The moment you start comparing it across teams or trending it upward as a goal, it stops telling you anything useful.