Posted on: April 23, 2025
This one comes up more often than it should — because it's deceptively simple, and dangerously easy to misuse.
Let’s get this out of the way: velocity is not evil.
It’s just a number — a tool for reflection. Like any metric, it can be useful when paired with context and judgment.
But here’s the trap: the moment you start chasing it as a goal, things break.
Teams start inflating story points. Breaking down work in artificial ways. Avoiding unknowns because they might “slow us down.” All in the name of “more velocity.”
Been there. I once saw a project that looked amazing on paper — velocity charts going up every sprint. Only problem? They did not ship it. They spent four million dollars and still hadn’t reached production. But hey — the metrics looked fantastic.
Here’s the deeper issue: velocity is a proxy. A rough indicator of throughput — not value. Specifically for developers - this is abstract proxy ;).
Code sitting in the repo doesn’t generate value. Only code in production — used, tested, delivering outcomes — matters.
And when management doesn’t see that distinction, velocity becomes a dangerous toy. A way to push harder, not smarter.
"We need to go faster!" Sure. But faster through what? Toward what? And at what cost?
My take?
Measure velocity if you want. But treat it like a indication, not a target.
Watch for patterns. Use it to ask better questions:
And always — always — pair it with qualitative signals: feedback, outcomes, trust, team health.
Because teams that feel pressured to deliver faster will eventually start "cutting corners". And the rework will eat all the “gains” and more.
Faster is slower, when you are speeding up recklessly.
Written by Ilya Komakhin