Velocity measures motion, not progress
I'll say it plainly: velocity is one of the most overrated numbers in delivery. Not useless, but overrated. It tells you the team is busy. It tells you the machine is running. It tells you nothing about whether the machine is going anywhere worth going.
I've watched teams run at full tilt, hit their commit sprint after sprint, close every ticket, and change absolutely nothing for anyone. Burndown chart looking gorgeous. Stakeholders nodding. And six months later you ask the simple question, the one nobody wants to ask out loud: what's actually different now? What problem got smaller? Which user has a better day because of all that motion?
Silence.
That's the gap between output and outcome, and most of our delivery rituals are built to ignore it.
We count what's easy to count
Here's the honest reason we obsess over story points, closed tickets, and velocity: they're easy. You can count them. You can put them on a slide. You can show a line going up and feel like you accomplished something.
Outcome is harder. "Did we reduce the cost of this operation? Did a transit rider actually get where they needed to go faster? Did we kill a risk that was about to bite us?" That's messy to measure. It takes longer to know. Sometimes you never get a clean number at all.
So we avoid it. We retreat to the counter we can read. And that's exactly the reason we have to force ourselves the other way. The thing that's hard to measure is usually the thing that matters. The easy metric is a comfort blanket, and comfort blankets don't deliver value.
A shipped feature is not a win
Let me be sharp about this one, because people get precious about it. Shipping a feature is not a success. It's an event. Whether it's a success depends entirely on what happens after it lands.
A feature nobody uses isn't a small win. It's a failure wearing a velocity costume. You spent real money, real hours, real focus from people who could have been working on something that mattered, and you produced a thing that sits there. The sprint board says "done." Reality says "why?"
I'd rather a team ship three things this quarter that move the needle than fifteen things that pad the throughput report. The fifteen feel productive. The three are productive. Those are not the same word.
Goodhart was right
There's a law worth tattooing on the wall of every delivery org. The moment a measure becomes a target, it stops being a good measure. Goodhart's law.
Watch what happens when you tell a team velocity is the goal. They don't get more valuable. They get better at the number. Points inflate. Tickets get sliced thinner so the count climbs. The estimate becomes a negotiation instead of a forecast. Nobody's lying exactly, they're just doing what you measured them on. You asked for a bigger counter, you got a bigger counter. The value didn't budge.
This isn't a people problem. It's a physics problem. Optimize for the proxy and you get the proxy, not the thing the proxy was supposed to stand in for. If you push velocity, you will get velocity, and you will be shocked at how little it buys you.
Even your best throughput metric is still output
I know what some of you are thinking. "Okay, points are garbage, but I use proper flow metrics. Cycle time, throughput, lead time." Fine. Those are better. They're cleaner, they're harder to game, they tell you something real about how work moves.
They're still output.
Flow metrics tell you the machine runs smoothly. They tell you work goes in one end and comes out the other at a predictable pace. They do not tell you the machine is pointed in the right direction. You can have flawless cycle time on a factory line that builds the wrong product, fast. Pretty is not the same as right.
So use flow metrics, sure. Just don't mistake them for the destination. They're about the road, not about where you're going.
The uncomfortable question outcome forces
Here's the part people skip, and it's the whole point. Measuring outcome forces a question that output lets you dodge: why are we doing this at all?
If I can't connect a piece of work to a concrete change, a cost that goes down, a user who's better served, a risk we take off the table, then maybe we shouldn't be doing it. That's an uncomfortable thing to say in a planning meeting. There's always a stakeholder who wants the thing because they want the thing. Output lets you serve them without thinking. Outcome makes you ask them to justify it, and makes you justify it back.
That question kills a lot of work before it starts. Good. That's the work doing its job. The best thing a team can do some weeks is decide not to build something.
The status report trap
This is where leaders fail quietly. Every reporting cycle you face a choice. You can show what's easy to present, the count of tickets closed, the velocity trend, the burndown. Or you can show the truth, which is harder and sometimes embarrassing: did any of this change anything?
The easy report always wins on a busy week. It looks great, it answers no real question, and everyone moves on feeling fine. The honest report sometimes says "we shipped a lot and moved nothing," and nobody wants to put that on a slide.
Put it on the slide anyway. A leader who only ever reports the flattering number is training the whole org to optimize for the flattering number. You become the reason Goodhart wins.
My actual job
So here's where I land it. My job as a delivery leader is not to push more output. The org has plenty of pressure pushing output already. It doesn't need me adding to the pile.
My job is to protect the focus on outcome. To keep dragging the conversation back from "how much did we produce" to "what did we actually change." Often that means delivering less, but the right less. It means defending a team's right to say no to work that can't justify itself. It means putting the unflattering truth in the report and eating the silence.
Give a team a crystal-clear objective, real constraints they all understand, room to figure out the how, and accountability for the result that actually matters. Then stop counting their motion and start asking what moved.
Velocity will tell you the team is busy. It will never tell you they're winning. Those are different questions, and only one of them is worth your time.