Velocity ≠ Speed: Stop Treating Your Sprint Ledger like a Speedometer

If your team brags about a 70-point sprint but half the work spills to next week, congratulations, you just bought a shiny bathroom scale and called it a Ferrari. 

Velocity is an accounting metric, nothing more. It tells you what the team “closed", not how fast they moved or how happy customers felt. Yet “how’s our velocity?” remains the first question leaders fire across the stand-up floor. In the 2024 State of Agile data set, velocity ranks as the most-used measure of “agile success.”

Where the confusion started

Early Scrum books described velocity as a simple planning aid: add up the story points finished in the last sprint and use that average to forecast the next sprint. Velocity mutated into a proxy for team performance somewhere between conference slides and executive dashboards. Blogs now warn that velocity has become the most abused agile metric ever. 

The math nobody reads. 

1. Velocity = sum of points Done inside the time-box.
2. If a story misses the Definition of Done, it earns zero points.
3. Partial credit inflates future forecasts and kills trust. 

That is it. Velocity is a historical ledger, not a racetrack timer (which most executives are trained to look for with teams). 

The Neuroscience Behind Relative Sizing. 

Humans perceive effort logarithmically (Weber-Fechner Law), which is why Modified Fibonacci buckets (1, 2, 3, 5 …) feel “just right” while hour estimates spark endless debate. Story points leverage that wiring; velocity tallies how many of those buckets you have completed. Mixing the two tells you “how big” and “how many,” without pretending to be a stopwatch. 

Three reasons velocity cannot measure speed.

State-of-Agile respondents say customer surveys, value-stream KPIs, and DORA metrics are rising sharply because leaders finally realize point totals do not equal value delivered. 

How to keep velocity honest. 

1. Lock your Definition of Done: no DoD, no points, full stop.
2. Ban partial credit. Return unfinished stories to the Product Backlog and live with the dip.
3. Average (or better yet, ranges), do not trend-line. Use a three-sprint rolling average to forecast capacity, treat outliers as learning moments, not performance reviews.
4. Publish outcome dashboards next to the burn-down. Throughput metrics tell you what happened, flow metrics tell you how, and outcome metrics tell you why it matters. 

A quick coffee-shop analogy: 

• Velocity is the number of drinks your barista closes in an hour.
• Speed is how quickly each latte moved from the grinder to the handoff.
• Customer Value is how many people come back tomorrow for another cup. 

Obsessing over velocity alone is like celebrating that you sold 100 coffees while ignoring that half were returned cold. 

So… should we ditch velocity?

No. Throwing it out would be like deleting your bank ledger because profit margin matters more than revenue. You still need a capacity gauge; we must stop treating it like a trophy, it's a piece of data that CAN help (or hurt).

Use velocity for: 

• Sprint forecasting
• Identifying sudden capacity shifts (new team members, holidays, blockers)
• Flagging process debt when carry-over spikes. 

Never use velocity for: 

• Team-to-team comparisons
• Individual performance rankings
• Management bonuses

Try this next sprint. 

1. Pick one user-facing metric: adoption rate, support tickets closed, revenue per active user.
2. Plot it next to your velocity chart.
3. Ask the team: Does higher velocity correlate with happier customers? If not, fix the system, not the score.