Most organisations do not fail because they cannot build software. They fail because they cannot consistently turn business intent into production outcomes. Yet when those same organisations measure delivery, they overwhelmingly measure the one thing that says least about whether intent ever became outcome: how much work the engineering team got through. Velocity. Story points. Throughput. Activity dressed up as progress.
This is not a new complaint, but it has become an urgent one. The translation layer between strategy, product, architecture, engineering and operations is the scarce capability in any delivery organisation. Measurement is supposed to illuminate that layer. Instead, the dominant metrics light up the easiest stratum to instrument and leave the rest in the dark.
Why velocity misleads
Story points and velocity were never designed to measure value. They were designed as a private planning aid for a team to forecast its own near-term capacity. The moment they leave the retro and become a performance target, Goodhart's Law takes over: a measure that becomes a target ceases to be a good measure. Beck and Orosz, responding to McKinsey's developer-productivity framing, put it plainly: output and effort metrics are simply the easiest things to count, which is precisely why they invite gaming. At Uber, they note, a metrics dashboard nudged engineers towards smaller diffs to keep the numbers healthy, quietly inflating continuous-integration cost in the process. Stack Overflow's engineering writing and the team at DX converge on the same conclusion from different angles: counting output manufactures perverse incentives and severs measurement from business impact.
The deeper problem is that output is uncorrelated with worth. Standish's CHAOS data, presented by Jim Johnson, found only around 7% of enterprise application features are 'always' used and 13% 'often', leaving roughly 64% rarely or never touched; later Standish work put about 80% of features at low or no value. Pendo's product analytics tell a similar story from the usage side. A team can hit every velocity target for a quarter and ship a quarter of pure waste. The dashboard will be green. The intent will have evaporated somewhere between the roadmap and the user.
The consensus alternative: balance, not a single number
No serious framework recommends one output figure. DORA's keys split deliberately into throughput (change lead time, deployment frequency) and stability (change failure rate, failed-deployment recovery time); the 2024 report added a fifth, rework rate, counting unplanned deployments to fix user-facing bugs. The SPACE framework spans five dimensions on purpose, including Satisfaction and Performance, to counter the single-metric myth. Kersten's Flow Metrics tie delivery flow back to revenue, quality and satisfaction. DX Core 4 follows the same instinct. The agreement across analyst, academic and standards sources is striking: measure flow and stability and value together, or you measure nothing useful.
If you want a starting scorecard, lead time and a stability signal are the most widely agreed health indicators. Pair change lead time with change failure or rework rate. Add a recovery measure. Then, and this is where most teams stop too early, instrument the value layer: time-to-value, adoption, retention, conversion, customer sentiment. SPACE's Performance dimension and the Flow Framework both insist these belong in the delivery scorecard, not in a separate product report nobody reads alongside the engineering one.
The translation audit: pair every speed metric with an acceptance metric
Here is the reframe we keep returning to in the field. Most frameworks instrument a single stratum. DORA and flow metrics measure the delivery engine. Pendo and product analytics measure the value layer. SPACE measures the human and team layer. Almost nobody instruments the full chain end to end: business intent, to validated outcome in production, to sustained adoption.
So treat the scorecard as a translation audit rather than a productivity dashboard. The rule is simple and uncomfortable: speed may never be celebrated without acceptance. Every throughput metric must be reported alongside a paired value or stability metric. Deployment frequency sits next to adoption of what was deployed. Lead time sits next to time-to-value. Volume of features shipped sits next to the fraction of those features that crossed a usage threshold. When the pairs diverge, the audit has found exactly what it is meant to find: a point where intent failed to become outcome. That is the signal. Busy engineers are not.
Why this gets dangerous in the AI era
Velocity is not merely wrong now; it is actively misleading in a way that worsens precisely when generation gets cheaper. DORA's 2024 analysis found that a 25% increase in AI adoption was associated with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in stability. Individuals feel more productive while the system delivers less, because larger AI-enabled batch sizes raise deployment risk. The 2025 'State of AI-assisted Software Development' work reinforced it, replacing performance tiers with seven archetypes and concluding that stability, not speed, remains the defining metric of delivery success. Thoughtworks' Technology Radar reaches the same place: in the AI era, DORA metrics matter more, not less. If lead times do not fall and deployment frequency does not rise, faster code generation has bought nothing. They propose first-pass acceptance rate as a leading indicator, which is exactly the acceptance signal the translation audit demands.
Once generation is cheap, output metrics inflate fastest precisely when they mean least. The constraint has moved from 'can we build?' to 'can we accept and sustain?'
This is the through-line to our broader thesis. AI accelerates execution; it does not fix Intent Translation. When generation is no longer the bottleneck, acceptance and sustained outcomes become the binding constraint. The centre of gravity of your scorecard must therefore shift downstream, towards time-to-value, adoption, and rework and defect rates, because that is where the new constraint lives.
Metrics for reflection, not surveillance
The last move is cultural, and it is where most measurement programmes quietly fail. Teams adopt metrics as surveillance dashboards aimed downward, and engineers respond rationally by optimising the number. The field-tested alternative, echoed by Thoughtworks, is metrics for reflection: owned by the team, surfaced in retros, used to ask why intent and outcome diverged. Pair that with outcome accountability rather than activity accountability. Beck and Orosz's heuristic, one customer-facing deliverable per team per week, is deliberately about a shipped, accepted outcome, not points burned down. It is crude, and that is its strength: it cannot be gamed by working harder at the wrong thing.
Where to start
Pick four pairs. Change lead time with rework rate. Deployment frequency with first-pass acceptance. Features shipped with adoption past a usage threshold. Throughput with time-to-value. Report them as pairs, never alone, and review them in the retro rather than the steering committee. The goal is not a tidier dashboard; it is to make visible every place where the organisation's intent stalled before becoming a sustained outcome. For how this scorecard fits a governance operating model, see Product Delivery Governance Without Bureaucracy; for the downstream constraint that should anchor it, see The Acceptance Gap; and for the engineering-specific extension in an AI-native delivery system, see Measuring AI Engineering Properly.