velocity and deploy frequency have become the default metrics engineering leaders reach for when trying to quantify team productivity, largely because they're easy to measure automatically from existing tooling. the problem isn't that these metrics are meaningless, it's that they're proxies for something else, and the gap between the proxy and the actual thing being approximated is wide enough, and exploitable enough, that optimizing directly for the proxy metric frequently produces behavior that actively works against the underlying goal the metric was meant to represent.
velocity measures estimation consistency, not throughput, and teams learn this quickly
story point velocity is fundamentally a measure of how consistently a team estimates its own work relative to its own past estimates, not an absolute measure of output that can be meaningfully compared across teams or even reliably tracked over time within a single team if the team's estimation habits shift. a team under pressure to show increasing velocity has a straightforward, low-effort path available that has nothing to do with actually delivering more value: estimate future work slightly more generously than past comparable work was estimated. this isn't necessarily a deliberate, cynical gaming of the metric, it often happens gradually and semi-consciously as a team absorbs the implicit signal that higher velocity numbers are viewed favorably.
the result is a metric that can show a clean, encouraging upward trend while the team's actual output and the actual complexity of what they're delivering remain essentially flat, or even decline, because the estimation baseline itself has quietly inflated. this is genuinely difficult to detect from the velocity trend line alone, since the drift happens gradually and the estimation inflation isn't visible in any single data point, only in a comparison against the actual, delivered complexity of the work over an extended period, which most organizations tracking velocity as a headline metric never actually do.
deploy frequency rewards splitting work into smaller pieces, independent of whether that's the right engineering choice
deploy frequency as a metric creates a direct incentive to break work into smaller, more frequently deployable units, and in many cases this is genuinely good engineering practice, smaller changes are easier to review, easier to roll back, and reduce the blast radius of any individual deployment going wrong. but the incentive doesn't distinguish between splitting work because smaller units are genuinely the better technical approach for that specific change, versus splitting work artificially to inflate the deploy count, shipping a feature across five small deploys that could have reasonably been one coherent deploy, specifically because deploy frequency is a tracked and visible metric.
a team optimizing directly for deploy frequency, rather than treating it as one useful signal among several, can end up producing a deploy history that looks impressively active while the actual pace of meaningful feature delivery and the actual quality of each individual change haven't improved, and in some cases have degraded, since artificially fragmenting coherent work into smaller pieces purely to inflate a metric can increase coordination overhead and integration risk rather than reducing it, inverting the actual benefit that legitimate small-batch deployment is supposed to provide.
what actually correlates with team health tends to be harder to measure automatically, which is exactly why it gets deprioritized
the metrics that more reliably correlate with genuinely healthy, productive engineering teams tend to require more deliberate, less automatable measurement, which is precisely why organizations gravitate toward velocity and deploy frequency instead, not because they're better signals, but because they're free to collect from existing tooling without requiring any additional deliberate measurement effort.
change failure rate, the percentage of deployments that result in a rollback, hotfix, or incident, measured over a meaningful time window, is a considerably more informative signal about whether a team's development process is genuinely sustainable, since a team can achieve high deploy frequency by shipping frequently but unreliably, which a pure frequency count wouldn't distinguish from a team shipping frequently and reliably.
lead time from code committed to code running in production, distinct from deploy frequency itself, captures whether a team's actual process, code review, testing, deployment pipeline, is genuinely efficient, versus a team that batches many small commits into infrequent large deploys that individually take a long time to actually reach production despite a superficially healthy-looking commit frequency.
developer-reported friction, specifically asking engineers where they lose time to process overhead, unclear requirements, flaky tests, slow ci pipelines, surfaces genuine productivity blockers that no automatically collected metric captures at all, since these frictions manifest as slower actual delivery without necessarily showing up as a clear signal in velocity or deploy frequency numbers, which measure output-adjacent proxies rather than the underlying friction actually constraining that output.
the deeper problem: any metric that becomes a target stops being a reliable measure
this pattern, a proxy metric becoming the actual optimization target and consequently losing its value as a genuine signal, is a well-documented dynamic that applies well beyond engineering metrics specifically, but it shows up with particular clarity in velocity and deploy frequency because both are unusually easy to game through low-effort behavioral adjustments, inflated estimation, artificial work-splitting, that don't require any actual change in underlying delivery capability or quality. this doesn't mean these metrics are worthless as one input among several, a genuinely severe, sudden change in either metric is still worth investigating as a signal something may have shifted. it means treating either metric as the primary or sole indicator of team health or productivity, and particularly using either as a direct performance evaluation criterion for individuals or teams, reliably produces the exact gaming behavior described above, which degrades the metric's own reliability specifically because it was elevated to a target rather than kept as one descriptive signal among a broader, harder-to-game set of indicators that actually correlate with sustainable, healthy engineering delivery.
Top comments (0)