Ask a team how they know they are agile and, more often than not, someone points at velocity. We finished 50 story points this sprint, up from 45, so we must be doing well. It feels like proof. It is easy to remember, easy to chart, and easy to report up the chain. The trouble is that velocity measures how busy you were, not whether anything valuable reached your customer. If that number doubled tomorrow, would your customers even notice? For a lot of teams, the honest answer is no.
None of this means velocity is evil. But it is quietly doing a job it was never designed to do, and it is crowding out the measures that actually tell you something. It is worth pulling the whole thing apart, retiring velocity as a scoreboard, and rebuilding the case for measuring what matters.
Velocity was never a metric
Start with the thing nobody says out loud. Velocity is not, and never has been, a metric. It is an internal planning tool, and it belongs to the team that uses it. Management likes it because it is a number, and numbers feel comparable, but that is exactly where it goes wrong. Velocity is relative to a single team’s estimation. One team’s story point is not another team’s story point, so lining up velocities to decide who is faster is meaningless. Worse, it is trivial to game. Inflate your estimates and your velocity climbs, while nothing about the actual work changes.
Velocity has been described as “yesterday’s weather”, and that is the right frame. It is useful for forecasting. If a team finished 35 points last sprint, is it on track for something similar this time? That is a fair planning question. It is useless for judging. The moment velocity becomes a performance scoreboard, teams optimize for the number instead of the customer, and you have taught them to look busy rather than to deliver.
The speedometer problem
Think of velocity as the speedometer in your car. It tells you how fast you are going. It tells you nothing about whether you are on the right road, headed in the right direction, or about to end up somewhere you never wanted to be. You can absolutely go faster. You can also go faster in the wrong direction, which just gets you to the wrong place sooner. Speed without direction is not progress, and a team that ships more points of the wrong thing has not become more agile. It has become more efficient at missing the point.
Outcome over output
The fix is to shift what you pay attention to, from output to outcome. Output is how much you built: six stories, two features, fifty points. Outcome is what changed because you built it. The question is not how much we shipped; it is what changed for the customer. Did they save time? Did behavior shift? Did we reduce a risk or earn some value? That is the thing worth measuring, and it is the thing velocity cannot see.
Watch the flow
If you retire velocity as a scorecard, what do you watch instead? Start with flow. Lead time measures how long work takes to move through your system, from a consistent start to a consistent end. The exact boundaries matter less than picking them and holding them steady. In Kanban, that is usually from the moment work starts to the moment it is delivered. What you are measuring is the honest thing: once we commit to a piece of work, how quickly can we turn it into value for the customer?
One caution here. Do not punish a team for how long an idea sat on the backlog before anyone prioritized it. That waiting time belongs elsewhere, not the delivery team. Measure the part the team controls, from start to finish. And when you look at how many items finish in a single sprint versus rolling into the next, use it to spot a flow problem, not to shame anyone.
Then there is work in progress, which may be the most underused idea in the room. When a team has too much in flight, everything stalls. People context switch, chase shiny objects, and finish nothing. Limiting work in progress is the antidote, and the phrase to keep in mind is stop starting and start finishing. A simple starting point is about one and a half items per person, so a team of four caps at six in progress at once. That number is a wild guess on day one, and that is fine. You try it, inspect, and adapt. Work in progress limits are an internal team tool, not a report you send upward. Get them right and lead time drops, flow speeds up, and the customer feels it.
Metrics that hold the whole organization accountable
Some of the most useful measures point the mirror back at the organization, not just the team. Emergent work per sprint, the unplanned work that lands mid sprint, is powerful for exactly this reason. It shows how often the business interrupted the team, and it turns a conversation about why the team is slow into a conversation about how the organization can protect focus. Flow efficiency, the ratio of value adding time to waiting time, tells a similar story about where work sits idle. And a positive one worth celebrating: number of sprints since the last rollover. A team on a ten sprint streak of finishing what it committed to has a success story worth telling.
Ask better questions
Ultimately this is about the questions leaders ask. Executives are not really wondering about your velocity or your feature count. They want to know whether the business moved forward. Did we grow revenue, reduce time to market, gain market share? Did we experiment, and what did we learn? Keep an experiment log and you can answer what your innovation rate looks like. As a leader, trade the old question for better ones. Instead of what was your velocity, ask what surprised us, what is slowing the flow, what decision got easier because of what we shipped, and what customer problem did we solve. Different questions pull different behavior.
What to take home
- Velocity is not a metric. It is an internal planning tool for the team, useful for forecasting and useless for judging performance.
- Speed without direction is not progress. A higher velocity in the wrong direction just reaches the wrong place faster.
- Measure outcome over output. Not how much you built, but what changed for the customer because you built it.
- Watch the flow. Lead time, work in progress limits, and stop starting, start finishing move the needle more than any point count.
- Use metrics that hold the organization accountable, like emergent work per sprint and sprints since the last rollover.
- Ask better questions. Trade what was your velocity for what changed, what did we learn, and what problem did we solve.
The bottom line
Velocity is easy to measure, which is exactly why it endures. But easy to measure is not the same as worth measuring. Optimize for customer outcomes, not internal activity, and the picture of your agility changes completely. Velocity is vanity. Outcomes are reality. Agility lives in the flow.