Velocity Is Not Progress: Case File 12, the Project That Finished Every Sprint

Velocity is the number of story points a Scrum team finishes in a sprint. That’s the entire definition. Teams use it for capacity planning — last sprint produced 38 points, so next sprint will probably absorb about 38 points of work — and for nothing else. It is a local, relative, effort-shaped number, invented by the team, meaningful only to the team. Its neighbors in the ritual toolkit are the burndown chart, the definition of done, and the sprint review. None of them measure progress. All of them measure the team’s activity, filtered through the team’s own estimates.

The failure I keep finding in post-mortems is a promotion problem. Someone carries velocity out of the team room and into a steering pack, sets it beside the budget, and asks a reasonable question: if the team burns 40 points a sprint, aren’t we 68% done? No. But by the time anyone asks, the number has usually been written into a charter, given a target, and assigned an owner. The project then dies green — every sprint completed, every burndown chart burned down, no customer any the wiser.

This is a case file. The artifacts are real, drawn from two anonymized post-mortems and lightly composited. The names are gone. The paperwork remains.

Case File 12: Project Meridian

• Project: “Meridian” (anonymized)
• Scope: replace a 19-year-old claims engine used daily by 300 staff
• Method: Scrum, two-week sprints, one team of nine engineers
• Duration planned: 12 months
• Duration achieved: cancelled in month 15, sprint 31
• Budget: £3.8 million. Written off: £3.1 million
• Cause of death (as recorded in the post-mortem): “insufficient velocity in later sprints”
• Cause of death (as recorded in this file): the project’s only progress instrument measured effort estimates, and effort estimates said everything was fine

Meridian finished every sprint it ever ran. Thirty-one departures, zero arrivals. The team beat its velocity target in six consecutive sprints before the plug was pulled. The dashboard was green for eleven months. This file is about how a team can run at full speed for a year and a half and cover almost no ground — and how the paperwork predicted it from month zero, to anyone willing to read the paperwork instead of the dashboard.

What Velocity Actually Measures

Answer first: velocity measures a team’s recent throughput of estimated work, in units the team made up.

Story points are relative. A story worth 8 points is “about twice” a story worth 4, by the team’s own feeling, on that day, in that mood. Points are not hours. They don’t convert to hours. They certainly don’t convert between teams — comparing two teams’ velocities is comparing two private languages and grading both on grammar.

Then there is what the method’s own manual declines to say. The 2020 Scrum Guide, the document every one of these charters claims descent from, never mentions velocity. It leaves measurement deliberately to the team. Meridian’s steering committee promoted a number the framework itself declines to prescribe, promoted it into a contract, and then expressed surprise when it behaved like a contract rather than a measurement.

The honest use of velocity is yesterday’s weather: assume next sprint resembles the last one, plan the sprint accordingly, revise when reality disagrees. That’s the whole job. A weather report for one farm.

The Moment a Measure Became a Target

From the charter, month 0:

“The team shall sustain a velocity of 40 story points per sprint. Velocity will be reported monthly to the Steering Committee as the primary indicator of delivery progress.”

Three errors, one sentence. A target attached to a unit with no fixed size. Monthly upward reporting of a team-local number. And the designation of that number as the primary indicator of progress — which is the sentence that eventually kills the project.

Goodhart’s Law, in Marilyn Strathern’s compact phrasing, holds that when a measure becomes a target, it ceases to be a good measure. Here is the mechanism, minus the economics-jargon costume. A team told to sustain 40 points will sustain 40 points. Not because anyone cheats — because points are elastic. A story sized at 5 in March is a 5 in March. Under target pressure, the same work is an 8 by June, and nobody is lying, because there is no fact of the matter. The unit has no anchor. Inflation is invisible by design.

No one in this file was stupid, and none of them lied. That is the finding. Every individual behaved rationally inside a structure that paid in points. Structures like that always settle their debts somewhere else. Meridian settled in month 14.

The Artifacts, Read in Order

Read in sequence, the paper trail tells the story the dashboard refused to.

The Status Reports (Months 2–11)

From the month-8 report, sprint 22:

“Velocity: 44 (target 40). Burndown: on track. RAG: GREEN. Overall completion: 61% (points consumed / points estimated). Notes: strong momentum into integration phase.”

Eleven consecutive months of green. The completion figure is the forensic centerpiece: points consumed divided by points estimated — a guess over a guess, formatted as a percentage. Percentages confer authority. Division does not check whether the numbers deserve it.

The denominator was 1,214 points, a total that assumed integration with the legacy claims engine was “about a 13.” By month 12 that work had consumed 340 points and wasn’t finished. The denominator had been wrong by an order of magnitude — cheerfully, in writing, for a year. The 61% was a real division applied to fictional operands.

The Definition of Done, Three Versions

“Done” is the load-bearing word in every velocity number. Meridian’s definition of done had versions.

Version 1, month 0: acceptance criteria met; automated tests pass; peer-reviewed; deployed to the integration environment; demonstrated at sprint review.

Version 2, month 5: “deployed to the integration environment” became “ready for deployment.” “Demonstrated at sprint review” became “demo where feasible.”

Version 3, month 9: the integration line was deleted. “Acceptance criteria met” became “acceptance criteria drafted.” No change record. No announcement. No email.

Shrink the definition and velocity rises without a single additional hour of work. Meridian’s velocity climbed 9% in the same quarter the word “deployed” left the building. This is how velocity and progress come apart — not through fraud, through version control on a definition, applied quietly, reviewed by no one.

The Risk Register Row Nobody Reopened

“RI-14 — Integration with legacy claims engine (‘Doris’). Impact: Critical. Probability: High (month 0) → Medium (month 3). Comment: ‘team confident.’ Owner: [redacted]. Last reviewed: month 3.”

At month 3, zero integration stories had been started. The downgrade from High to Medium was produced by a good sprint review and a room full of momentum. A risk register is a list of things a project promised to keep thinking about. This one was a museum of month-0 honesty, curated once.

Doris was 19 years old, held together by a nightly batch job and one contractor’s memory. She was the entire project wearing a disguise, and the register last mentioned her in March.

The Email Thread That Answered a Different Question

Month 12, redacted:

[Redacted, Steering Committee]: Twelve months in. The dashboard says 68%. When does a customer first touch this system?

[Redacted, Delivery Lead]: Velocity is trending up 9% quarter over quarter and has beaten target for six consecutive sprints. At current velocity the remaining backlog clears in five sprints.

[Redacted, Steering Committee]: That is not an answer to my question.

[Redacted, Delivery Lead]: [400 words, redacted. The phrase “burndown chart” appears four times.]

The question was denominated in outcomes: a customer, using the system. The answer was denominated in effort: points, per sprint. There is no exchange rate between the two.

The delivery lead wasn’t evading. He was reporting faithfully, in the only unit the dashboard had ever taught him. The committee member wasn’t hostile. He was asking the only question that mattered. Two honest people, two unit systems, no converter. That thread is the whole death in four emails.

Why the Dashboard Stayed Green

Because every instrument on the dashboard measured the team, and nothing measured the world.

Legibility beats importance. Velocity exists, so it gets reported. Progress toward an outcome mostly doesn’t exist as a number, so it gets a paragraph of prose nobody reads. Dashboards fill with whatever is countable, not with whatever matters.

Wrong instrument. Points estimate effort. Progress is the world’s verdict on software in production. An estimate is a belief; a deployed increment is a fact. Beliefs are cheaper, and they arrive two weeks early.

The cadence. A two-week sprint manufactures the sensation of arrival 26 times a year. Completion rituals without completion. Meridian’s sprint train departed on schedule every fortnight and never once arrived anywhere. Departure is not arrival.

The genre. Status reporting is a genre with a rich vocabulary for “nearly” and no sentence at all for “stopped.” Eleven consecutive greens is not evidence of health. It is evidence of a genre doing its job.

The geometry of the burndown chart. A burndown chart is drawn to end at zero. It cannot stay wrong. A chart that structurally cannot show the truth until the final day is a decoration, not an instrument.

In month 14, a committee member asked a question the dashboard had no field for: of the 214 stories marked done, how many could a real user actually use today? The team went away and counted. Eleven.

The project was cancelled at sprint 31. The post-mortem recorded “insufficient velocity in later sprints” as the cause of death. The obituary used the wrong unit. They usually do.

What Velocity Is Actually For

Answer first: sprint planning and short-horizon forecasting, inside one team, with no audience.

Used properly, velocity is a capacity heuristic. It is also, occasionally, the most honest thing on the dashboard — in the other direction. When Meridian’s velocity dipped in month 8, the retrospective blamed “story complexity.” The actual cause was two engineers spending their days inside Doris’s database, untangling. The dip was the world trying to file a report. Nobody read it, because dips read as failure and the target was 40.

Its illegitimate uses are the ones that acquire an audience: cross-team comparison (unitless units, twice); individual performance reviews (attach pay to points and watch the points grow); charter targets; percent-complete arithmetic; “industry velocity” benchmarks sold by consultancies who should know better.

Reporting Progress Without the Costume

If you are the one who has to stand in front of a steering committee, here is what worked in the projects that lived.

• Report in outcome units. “A claims handler can submit and reject a claim on the new path, in staging, today.” One sentence like that outranks a quarter of burndown charts.
• Build the walking skeleton first. A thin, ugly, end-to-end slice in the first quarter pays the integration risk early, while it is cheap. Meridian deferred Doris until month 10, when she was expensive and furious.
• Demo the riskiest thing, not the newest thing. Sprint reviews that parade the shiniest finished work are marketing. Sprint reviews that poke the scariest unfinished work are due diligence.
• Count what the world received. Deployed, usable increments. Days since the last production change. Remaining scope phrased as outcomes, not points.
• Track flow, not faith. Throughput of finished and released work items, cycle time, and a cumulative flow diagram will show work aging in place — a thing no burndown chart can do. For delivery health, the four DORA measures — deployment frequency, lead time for changes, change failure rate, time to restore — have the property velocity lacks: they are measured at the system the customer actually touches.

And one rule for steering packs, which I now apply to every percentage I am handed: every figure must name its numerator and denominator out loud, in outcome terms, or it does not go in the deck. If it has not been used by someone outside the team, it is not progress. It is inventory.

Early Warning Signs

If you inherit a running project, read these before you sit through a single sprint review.

1. Done stories in three figures; users in none.
2. A percent-complete figure that can only be produced by dividing points by points.
3. A definition of done with versions — and the later versions are shorter.
4. Stable velocity, slipping dates. When the two disagree, believe the dates. They are the only number in the pack with a spine.
5. Risk register rows about integration untouched since kickoff, while dependent work keeps “completing.” Completing work that depends on an unopened risk is not progress. It is debt with a green background.

FAQ

Is velocity a bad metric?

No. It is a badly promoted one. Velocity is a reasonable capacity heuristic for a single team and, when it drops, occasionally the most honest signal on the board. It turns toxic the moment it acquires an audience, a target, or a payroll attached. Keep it inside the team and it behaves.

Can you convert story points into percent complete?

You can divide them. The result is a number, not a percentage of anything. Points estimate effort; progress is measured in delivered outcomes; and the estimated total changes every time the work teaches you something. In Meridian’s case the denominator was wrong by an order of magnitude, so the 68% was arithmetic applied to fiction.

What should a steering committee ask instead of “what’s the velocity?”

Three questions. What can a user do now that they could not do last month — show me, don’t chart it. When was the last change in production, and what did it change? What is the riskiest unfinished thing, and who has looked at it this month? None of these produce a tidy line for a dashboard. That is a feature.

Why does velocity often rise just before a project collapses?

Because by then the number has changed jobs. Target pressure inflates points. Slipping milestones encourage story-splitting. A shrinking definition of done converts half-finished work into completed work overnight. The velocity isn’t lying, exactly. It has simply stopped being an instrument and started being a narrative device — without a job posting to mark the transition.

The Next File

Meridian’s steering pack contained one more artifact I have not shown you: a milestone tracker that read “80% complete” for five consecutive months. That is the next case file.

I am also assembling a glossary of fatal phrases. “On track” is drafted. “68% complete” is drafted. “Ready for deployment” is under review. If you are sitting on a charter clause, a risk register row nobody has reopened since kickoff, or a redacted thread that answers a different question than the one asked, send it in.

Organizations rarely fail because people stop trying. They fail because every instrument on the wall said keep going. Dead projects leave excellent paperwork. The least the living can do is read it carefully.