"Velocity Is a Lie – And Everyone Knows It"

February 2026 9 min read Opinion + Case Study

Every Scrum team tracks it. Every manager asks about it. And almost nobody trusts it. Velocity is the most widely used metric in Agile – and arguably the most misunderstood one.

The Reality: A Number That Feels Like Progress

Walk into any Scrum team’s sprint review and you’ll see it on a chart. Story points completed per sprint, plotted over time, trending hopefully upward. The team reports 34 points this sprint, up from 28 last time. The manager nods. Progress.

But ask a harder question: progress toward what, exactly?

Velocity was designed as a planning tool – a way for teams to predict how much work they can realistically take on in a sprint. That’s it. It was never intended to measure productivity, quality, team performance, or business value delivered. Yet somewhere along the way, it became all of those things.

“Velocity is a capacity planning tool, not a performance indicator. The moment you use it to judge a team, you’ve broken it.” Markus – agile-checksum.com

The State of Agile Report consistently shows velocity as one of the top metrics organisations track. It’s visible, it’s numerical, it feels objective. Which makes it perfect for dashboards – and dangerous for decision-making.

---

The Checksum: What Velocity Actually Measures

Let’s go back to basics. The Scrum Guide doesn’t mention velocity at all. Not once. It’s a community practice that emerged from the need to forecast sprint capacity – and that context matters enormously.

The Three Fundamental Problems

Velocity has three structural flaws that make it unreliable as anything other than a rough internal planning tool.

1. Story Points Are Not Standardised

A 5-point story in Team A means something completely different to a 5-point story in Team B. Story points reflect a team’s relative estimation of effort and complexity – they are deliberately subjective and team-specific. Comparing velocity across teams is therefore meaningless. It’s like comparing temperatures in Celsius and Fahrenheit without converting: the numbers look similar, but they mean entirely different things.

Glossary: Story Points are a unit of measure for expressing the overall size of a user story, feature, or other piece of work. They represent effort, complexity, and uncertainty – not hours.

2. Velocity Inflates Under Pressure

This is the one everyone knows but nobody says out loud in the sprint review. When management starts tracking velocity as a performance indicator, teams – consciously or not – adjust their estimations upward. Stories that were 3 points become 5. The velocity climbs. The work doesn’t change. Everyone feels better. Nothing improves.

This is a textbook example of Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure.

3. Velocity Ignores Value

A team can have consistently high velocity and deliver almost no business value. They’re completing stories, hitting their numbers, and shipping features nobody uses. Velocity measures output, not outcome. And in Agile, outcomes are supposed to be the point.

Red Flag: If your organisation is using velocity to compare teams, set targets, or make hiring decisions – stop. You are measuring the wrong thing and creating the wrong incentives.

---

Real-World Examples: What I’ve Seen in the Field

Over 20 years in enterprise IT, I’ve seen velocity misused in ways that range from mildly counterproductive to genuinely damaging. Here are three anonymised patterns I’ve encountered repeatedly.

The Velocity Race

A large financial services organisation – multiple Scrum teams, common portfolio, shared quarterly planning. Someone in leadership had the idea to display all teams’ velocities on a shared dashboard. Publicly. Updated weekly.

Within two sprints, average story point estimates across all teams had increased by roughly 40%. The work hadn’t changed. The teams had simply recalibrated their estimates upward to avoid appearing at the bottom of the leaderboard. When I pointed this out in a retrospective, the response from one senior developer was: “We all knew it was happening. Nobody wanted to be the team that looked slow.”

The Velocity Contract

A mid-sized software company negotiating a development contract with an external Scrum team. The contract included a clause specifying a minimum velocity of 60 story points per sprint. The external team agreed.

By sprint three, they were consistently hitting 65-70 points. Impressive – until the internal stakeholders noticed the quality of deliverables was declining, bugs were increasing, and the Definition of Done was being quietly stretched. High velocity, low value. The contract metric was met. The project failed.

The Velocity Plateau

A product team I coached had maintained a stable velocity of around 45 points for six months. Their manager considered this a problem – surely they should be getting faster? He pushed the team to increase velocity by 20% within the next quarter.

What he didn’t understand: a stable velocity is often a sign of a healthy team. It means estimation is consistent, technical debt is being managed, and the team isn’t overcommitting. A stable velocity isn’t stagnation – it’s reliability. Which is what you actually want from a planning tool.

---

What the Numbers Actually Show

The irony of a section titled “what the numbers show” in an article about the danger of numbers is not lost on me. But let’s use data correctly – as context, not as verdict.

Velocity Used As…	What It Measures	What It Misses
Sprint capacity planning	How much a team can take on	Quality, complexity variance
Team performance indicator	Story points completed	Business value, outcomes, quality
Cross-team comparison	Nothing meaningful	Everything that matters
Progress reporting to management	Output activity	Whether the right things are being built
Contract performance metric	Compliance with a number	Value delivered, quality, sustainability

---

Better Alternatives: What to Measure Instead

Criticising a metric without offering alternatives is just complaining. So here’s what I’d recommend instead, depending on what you’re actually trying to understand.

If You Want to Measure Team Health

• Sprint Goal achievement rate – Did the team deliver what they committed to at sprint planning? This measures reliability and focus.
• Escaped defects – How many bugs made it to production? A rising number here is a sign of quality problems velocity will never show you.
• Team satisfaction score – A simple 1-5 scale in each retrospective. Declining scores predict problems before they become visible in any output metric.

If You Want to Measure Business Value

• Outcome metrics – User adoption, conversion rates, support ticket volume, whatever is relevant to the product. These are the metrics that actually tell you if the work matters.
• Cycle time – How long does it take from “story started” to “in production”? This measures flow efficiency, not team speed.
• Net Promoter Score (NPS) – For customer-facing products, user satisfaction is the ultimate output metric.

If You Need to Report Upward

Practical tip: Replace velocity charts in your management reporting with a simple “Sprint Goal Met / Not Met” indicator plus a one-sentence explanation of why. It’s more honest, more meaningful, and takes less time to produce.

---

The Takeaway: Use It for What It Was Built For

Velocity isn’t useless. Used correctly – as an internal, team-specific, sprint-to-sprint planning reference – it’s a perfectly reasonable tool. The problem is never the tool itself. The problem is what happens when a planning heuristic gets promoted to a performance indicator.

The moment velocity appears on a management dashboard, the moment it’s used to compare teams, the moment it becomes a target – it starts distorting the behaviour it was supposed to support. Teams stop estimating honestly. Quality erodes quietly. And everyone pretends not to notice because the number looks good.

Run the checksum on your organisation. Ask these three questions:

1. Who has access to your team’s velocity data, and what do they use it for?
2. Has your velocity been steadily increasing without a clear reason why?
3. Could you tell me, right now, what business value last sprint’s velocity actually delivered?

If the answers make you uncomfortable – that’s the point. Discomfort is where honest conversations begin.

“The goal of Agile is not to go faster. It’s to learn faster. Velocity measures neither.” Markus – agile-checksum.com

---

Glossary Terms Used in This Article

• Velocity – A measure of the amount of work a Scrum team completes during a sprint, expressed in story points.
• Story Points – A relative unit of estimation reflecting effort, complexity, and uncertainty.
• Definition of Done – The shared agreement on what “complete” means for a product increment.
• Technical Debt – The implied cost of rework caused by choosing a quick solution now instead of a better approach.
• Sprint – A fixed time-box of 1-4 weeks in which a Scrum team delivers a potentially releasable increment.