Velocity is a planning metric, not a value metric
Article content
Article sections
Early in my career I heard a story from another coach that I have been telling, in some version, ever since. Two scrum teams at the same company. Same product, same general experience level, same kind of work. One delivered for years at a steady, predictable pace; the other, after a quiet conversation with a well-meaning VP, started delivering double, then triple, then a million times the velocity of the first. None of the work changed. None of the value changed. Only the number on the velocity chart changed. The VP had no idea. Most VPs, in my experience, still do not.
If you are an agile leader and someone is comparing the velocity of two teams in front of you, the conversation is already broken; you are just standing in the room before anyone has noticed. Velocity is a planning metric, not a value metric. A team's velocity is an instrument it built for itself, in its own units, against its own definition of done. Compare two of them and what you have learned is not which team is faster; it is which team has been pressured hardest into changing its instrument.
The Thunder and Lightning fable
Here is the version I tell in our CSP-SM classes. Names changed for the obvious reasons, but the shape is real.
It is a bright Wednesday morning. The VP of Product (call her V) walks into a sprint review for Team Lightning. Team Lightning's velocity is off the charts, nearly double Team Thunder's, which up to that point had been seen as a model of steady delivery. V leaves the room impressed. She walks across the floor to Team Thunder's review the same afternoon. "Team Lightning is delivering twice as much value as you," she tells them, kindly. "I need you to step up. Can you increase your velocity?"
Team Thunder's Scrum Master, who has been on a few rodeos, pauses thoughtfully. "No problem at all," he says, calmly. V leaves the room pleased.
At their next sprint planning session, Team Thunder huddles together with what I am told was a faintly mischievous look in their eyes. They do not change a single practice. They do not write a single additional line of code. They do not deliver any additional real-world value to a single customer. They simply decide to multiply every story point estimate by one million.
Two weeks pass. The next sprint review arrives. V attends, hopeful. At the close of the demo Team Thunder's Scrum Master stands up and announces, with the gentlest possible smile, "We have improved our velocity by exactly one million story points this sprint." The room is quiet for a moment. V looks confused. "How is this possible? Did you deliver one million times the value?"
"Not quite," he says. "We just adjusted our estimates."
What Team Thunder did, in the fable, is an exaggerated version of what every team in the world does the moment its velocity becomes a thing people talk about up the chain. The exaggeration is for teaching purposes; the move itself is universal. Tell a team its velocity is being compared, and you have told the team that its velocity is now political. Politics applied to estimates produces estimate inflation, which produces velocity inflation, which produces precisely no additional value. The work does not move faster. The numbers do.
Goodhart's law, restated for agile leaders
The economist Charles Goodhart said, in 1975, that when a measure becomes a target, it ceases to be a good measure. The line has been restated about ten thousand times since then, often by people who have never actually been on the receiving end of a measure that became a target. The restatement that matters in the agile context is shorter: any metric you compare across teams will be gamed. Not maybe gamed. Will be gamed. The only variables are how long it takes and how creative the gaming gets.
The reason this is structural rather than ethical is that teams are not idiots. A team subjected to a metric-as-target will, very quickly, work out which inputs to that metric they control. Story-point inflation is the most visible move; it is also the least interesting. The more interesting moves are subtler. Splitting work into smaller stories to bump the count. Refusing to take stories that score badly on the metric. Quietly reclassifying defects so they do not count. Shortening sprints. Lengthening sprints. Reframing "done" so more of the work is considered done before the sprint ends. None of these are dishonest. Each of them is the team optimising for the thing the leader said matters most. The leader said the wrong thing.
The call-center pattern at scale
The clearest version of this I have seen outside agile is the call-center industry, which has been refining metric-gaming behaviour for thirty years. When call-handle time becomes the headline metric, agents start putting callers on mute instead of on hold so the timer keeps moving favourably. When transfer rate becomes the headline metric, agents transfer calls to other departments mid-resolution. When first-call-resolution becomes the headline metric, agents hang up on callers whose issues will not resolve in the first call. Every one of these moves is rational behaviour under the metric the leader chose. None of them helps a single customer.
The agile equivalent is identical in shape, just dressed differently. Velocity. Story points completed. Sprint commitment ratio. Days to first comment on a pull request. Tickets closed per engineer per week. Each of these can be useful inside a team that has set it for itself and uses it to plan its own next move; each of them becomes corrosive the moment it is compared across teams or, worse, turned into an OKR target. The leader, in good faith, is asking for visibility. The team, in equally good faith, gives the leader visibility into a metric that no longer reflects anything real.
What to ask instead
The fix is not to abolish velocity. Inside a team, used as a planning instrument, velocity is exactly what it was designed to be. The fix is to stop asking the team about velocity in the comparison frame, and start asking about value in the only frame that makes sense, which is the frame of the work itself. Most VPs I have coached through this can change their question in a single conversation if you give them the script.
The reframe, in three turns
"Team Lightning's velocity is nearly double Team Thunder's. Why is Team Thunder so slow?"
"Their numbers are calibrated to different things, so the comparison does not work the way it looks. Can I show you the four releases each team has shipped in the last quarter, and what each release was worth to the customer?"
"Sure. What am I looking at?"
"Team Thunder shipped two releases, both customer-priority, both adopted by more than half the existing user base within a week. Team Lightning shipped six releases, four of them internal or maintenance, two customer-facing, with low adoption. Velocity says Lightning wins; value delivered says Thunder. The teams are doing different work and they are calibrated for it differently. If you want to know which team is delivering more value, this is the picture; if you want to know which team estimates in smaller pieces, the velocity chart is the picture. I think you want the first one."
That is the entire reframe. It works because it does not refuse the leader's question; it answers a slightly better version of the question they were trying to ask. If your VP is well-meaning and has been pulled into the velocity comparison habit by an analyst or a dashboard, the script above works the first time you use it; if they have been pulled in by a board that has been asking the wrong question for two years, it takes a few rounds. Both happen. Both are recoverable. The team is recoverable too, even if it has been doing the estimate inflation move for a while, because once the comparison pressure stops the inflation stops, and within two or three sprints the velocity number goes back to representing what it is supposed to represent.
What to do this week
If you are a Scrum Master or coach whose teams are being velocity-compared right now, do not try to win the metric argument frontally. Pull the relevant VP aside before the next portfolio review and run the three-turn reframe above on whatever artefact is going to be shown. Do it in private; the public version of this conversation almost never lands. Most agile leaders I have worked with hear the reframe the first time and change the question; some take two passes. Almost none refuse it. They have just not been given the slightly better question to ask.
If polarity thinking is the longer lens you want for this conversation, Brock's Integrated Agile Manifesto piece walks the same move on the original Manifesto: every metric pair you have been treating as a comparison is probably a polarity instead. And the original Goodhart's Law Wikipedia entry has the academic version of the result if you would like to send it up the chain with the script.
Write back when the welcome email lands if you would like a second pair of eyes on the next velocity conversation you are dreading. Most of what surfaces in those conversations is that the leader has been measured the same way by their board, and the conversation up is the same shape as the conversation down. Brock and I both read the replies.