Somewhere in almost every technology organisation, a slide is being prepared for a leadership meeting that shows velocity trending upward. The person preparing it believes it demonstrates progress. The person receiving it believes it represents delivery. Neither is correct.
Velocity — measured in story points — tells you one thing: how much effort the team estimated it would spend. It tells you nothing about what was delivered, whether it was valuable, or whether customers noticed. It is a planning input masquerading as a performance output, and the confusion between the two is costing organisations far more than they realise. Not in money — though the financial cost is real — but in attention. Leadership attention is finite. Every minute spent discussing velocity is a minute not spent discussing outcomes, value, or strategic direction.
What velocity actually measures
Velocity is the sum of story point estimates completed in a sprint. Story points are relative estimates of effort, created by the team, for the team. They were never designed to be reported upward. They were designed to help teams plan their sprints — nothing more.
The original intent was straightforward: if a team completes roughly 40 points per sprint, and the next sprint's backlog contains 42 points of work, the plan is reasonable. That is the entire purpose. It is a calibration tool. It helps a team answer the question: can we commit to this amount of work in this timeframe?
When velocity is reported to leadership, it becomes something it was never meant to be: a performance metric. And performance metrics get gamed. They get compared. They get used to justify funding decisions and restructuring proposals. A number that was designed to help eight people plan a fortnight of work is now shaping investment decisions worth millions. The absurdity of this should be self-evident, but it persists because the number is easy to produce, easy to chart, and easy to present. Ease of measurement is not the same as value of measurement.
The gaming problem
When velocity becomes a target, teams inflate estimates. A task that was 3 points becomes 5. Leadership sees velocity increase by 40 per cent. Nothing has changed. The same work is being done at the same pace. But the number looks better, so everyone is satisfied.
This is Goodhart's Law in action: when a measure becomes a target, it ceases to be a good measure. The moment a team learns that its velocity is being reported to leadership — and that leadership interprets higher velocity as better performance — the team has every incentive to estimate generously. They are not being dishonest. They are responding rationally to the system they have been placed in. The dysfunction is not in the team. It is in the governance structure that chose to use an internal planning metric as an external performance indicator.
Velocity reported upward is not a measure of delivery. It is a measure of how well teams have learned to give leadership the numbers it wants to see. The metric is not broken — it was never designed for the purpose to which it has been applied.
The false equivalence
Story points are not fungible. Ten points from Team A is not equivalent to ten points from Team B. Each team calibrates its own scale based on its own context, codebase complexity, and historical experience. You cannot aggregate velocity across teams. You cannot compare teams by velocity. You cannot use velocity to calculate capacity or predict delivery dates with any reliability.
And yet organisations do all of these things, every sprint, and make decisions based on the results. They create dashboards that sum velocity across the portfolio. They rank teams by velocity per engineer. They use velocity trends to forecast programme-level delivery dates. Every one of these practices is statistically meaningless. The numbers are presented with precision — two decimal places, trend lines, rolling averages — but precision is not accuracy. A precisely wrong number is still wrong.
The danger is not that the numbers are imprecise. The danger is that they create confidence. Leadership sees a chart trending upward and believes delivery is improving. They see a number attached to a team and believe they understand that team's performance. The chart and the number provide certainty where none exists. And certainty without foundation is more dangerous than acknowledged uncertainty, because it discourages the questions that would reveal the truth.
What to report instead
If leadership needs to understand delivery performance — and it should — give them metrics that actually connect to value. Four measures matter more than velocity ever could:
- Lead time. How long does it take from an idea being approved to a customer being able to use it? This measures the entire system, not just the development team. It reveals structural bottlenecks, handoff delays, and governance overhead.
- Deployment frequency. How often does value reach customers? Organisations that deploy frequently have shorter feedback loops, lower risk per release, and greater ability to course-correct.
- Customer-facing outcomes. What actually changed for the user? Did adoption increase? Did task completion improve? Did support contacts decrease? These are the measures that connect technology investment to business value.
- Throughput of strategic initiatives. Are the big bets progressing? Not whether stories are being completed, but whether the strategic objectives behind those stories are advancing. This requires leadership to define what success looks like before work begins — which is itself a discipline most organisations lack.
These are harder to measure than story points. They require cross-functional data, clear outcome definitions, and governance structures that track value rather than activity. That difficulty is precisely why they are more valuable. Easy metrics are easy because they measure what is convenient, not what matters.
Why this matters structurally
The choice to report velocity to leadership is not just a measurement problem — it is a governance problem. It shapes what leadership pays attention to. If they see velocity, they ask about velocity. They make decisions based on velocity. They fund teams that show high velocity. They question teams whose velocity dips, regardless of whether those teams are delivering the most strategically important work in the organisation.
The entire governance structure optimises for the wrong thing. Teams optimise for points completed rather than outcomes delivered. Product owners prioritise stories that are easy to estimate and quick to finish rather than stories that are strategically important but uncertain. The portfolio looks productive. The business sees no change.
Changing the metric changes the conversation. Changing the conversation changes the decisions. If leadership asks about lead time, teams focus on removing bottlenecks. If leadership asks about customer outcomes, product owners prioritise work that delivers measurable value. If leadership asks about strategic throughput, the portfolio aligns to business objectives rather than delivery volume. The metric you report is the behaviour you incentivise. Choose accordingly.
The bottom line
Velocity is a team planning tool. It is not a business metric, a performance indicator, or a measure of value. Reporting it to leadership creates a false sense of progress that obscures the questions that actually matter: Are we delivering the right things? Are customers experiencing the benefit? Is the strategic direction advancing?
Stop reporting velocity upward. Start reporting outcomes. The conversations will be harder, the metrics will be less tidy, and the charts will require more explanation. That is not a weakness. That is what honest governance looks like.