The Four Delivery Metrics That Predict Engineering Velocity (And the Two That Mislead You)

Last updated: August 25, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

Four delivery metrics predict engineering velocity: change lead time, deployment frequency, change fail rate, and failed deployment recovery time. Story-point velocity and sprint completion rate predict almost nothing, because both are calculated from the estimate rather than from the delivery.

I sat in a quarterly business review two years ago where a VP of Engineering opened with a chart showing velocity up 22% over three sprints. Good slide. Clean trend line. He had rehearsed it.

The CEO let him get about ninety seconds in and then asked one question. “Did anything reach a customer faster?”

Nobody in the room had that number. Not the VP, not the two directors sitting behind him, not the product lead who had helped build the deck. They had spent a quarter improving a figure that could not be converted into the only unit the CEO cared about, and the meeting turned into forty minutes of defending a measurement instead of ten minutes of funding a plan. I have watched some version of that happen at least a dozen times since, usually to leaders who are genuinely running good teams and simply brought the wrong instrument to the room.

This piece is about which instruments hold up. KORE1 publishes it because the same failure keeps showing up in their engineering staffing conversations, where a client is convinced they need three more engineers and the delivery data says the constraint is somewhere else entirely.

The Question That Ends Most Engineering Slides

Every metric an engineering leader reports upward gets tested the same way, whether or not anyone says it out loud. Can somebody outside engineering verify it? Does it move when the business gets what it wants?

Two questions. Everything else is presentation.

Story points fail both tests instantly. They are an internal accounting unit, defined differently by every team in your own company, and a CFO who has spent twenty years reading numbers that mean the same thing across departments will treat yours as unverifiable the moment she understands how they are set.

That is not hostility toward engineering. It is the correct read.

The four metrics below pass both tests because none of them originate inside a planning tool. They come out of version control and the deployment pipeline, which are systems nobody on your team edits to make a chart look better. This is the Clarity Stack applied to measurement, and it is the same principle underneath all three layers of it. If the number lives where anybody can go check it, the conversation about it stays honest.

What DORA Actually Publishes Now, and Why It Is Five

Here is a detail that will separate you from every vendor guide your exec team has skimmed. DORA does not publish four metrics anymore. It publishes five, split into two groups, and the split is not cosmetic.

Three are throughput metrics. Two are instability metrics. You need one from each column or neither number means anything.

On the throughput side, DORA defines change lead time as “the amount of time it takes for a change to go from committed to version control to deployed in production.” Deployment frequency is simpler. It is “the number of deployments over a given period.” Failed deployment recovery time covers “the time it takes to recover from a deployment that fails and requires immediate intervention.”

Then the instability group. Change fail rate is “the ratio of deployments that require immediate intervention.” Deployment rework rate is “the ratio of deployments that are unplanned but happen as a result of an incident in production.” Two ways of counting the same underlying thing, which is how much of your deploy volume is your team cleaning up after itself.

Four of those five belong on an executive slide. Rework rate is the newest of them and the hardest to instrument cleanly on a first pass, so I treat it as the one you graduate into after the other four are trustworthy.

Two changes are worth knowing because someone will eventually correct you on them. Mean time to recovery was renamed in 2023, and the reason is a good one. The old definition, per DORA’s own history of the metrics, “did not distinguish between a failure initiated by a software change and a failure caused by external factors, such as a data center outage.” A regional cloud outage was making delivery teams look bad for something they did not do. Fair fix. Rework rate arrived in 2024, after the researchers concluded change fail rate had been quietly serving as a proxy for how much of your deploy volume is reactive.

The Two Numbers That Say How Fast

Change Lead Time

This is the number I ask for first when I walk into a new org. Commit to production. Not ticket creation to production, which measures your product backlog grooming habits, and not story start to story done, which measures nothing at all.

Lead time is a queue measurement wearing a delivery costume. When it is long, the extra hours are almost never spent writing code. They are spent waiting: waiting for review, waiting for a shared staging environment, waiting for a release train that leaves on Thursdays, waiting for a compliance sign-off that one person is authorized to give and that person is at a conference. In mortgage tech I have seen a two-hour code change carry an eleven-day lead time, and every one of those days was a handoff, not an engineering problem. Eleven days. Two hours of actual work.

Break it into segments before you report it. Commit to PR open, PR open to first review, first review to approval, approval to merge, merge to production. The segment holding the most time is your constraint, and it is usually one you can name in a sentence. Usually it is review.

Deployment Frequency

Deployment frequency is the closest thing engineering has to a batch-size gauge. Teams that deploy daily are shipping small changes. Teams that deploy every three weeks are shipping accumulations, and an accumulation is harder to test, harder to review, and much harder to roll back when it misbehaves at 2am on a Saturday.

It is also the metric most likely to be gamed by an over-eager team once you start reporting it, which is why it never travels alone. More on that below.

One caveat for anyone in a regulated environment, and I have spent most of my career in one. Deployment frequency does not mean you ship unreviewed code into a lending platform. It means the release mechanics are cheap enough that shipping small is the default rather than an event that requires a meeting. That is the point.

The Two Numbers Most VPs Leave Off the Slide

Change Fail Rate

The percentage of your deploys that need an immediate rollback or hotfix. That is the whole definition.

Engineering leaders hide this number, and I understand the instinct. It looks like an admission. It is actually the single strongest credibility move available to you in an executive meeting, because reporting a failure metric next to a speed metric tells the room you are not selling them anything. I have watched a VP present a change fail rate of 14% and get more budget than a peer who presented a flawless throughput chart, purely because the first one was believable. Believability compounds.

Failed Deployment Recovery Time

How long from a deploy going wrong to service being restored. Under the current definition it is scoped to failures your own change caused, which is what makes it fair.

DORA files this one on the throughput side of its own split, because it measures a duration rather than a ratio. I report it next to change fail rate anyway. In a room full of executives, the two answer the same question, which is what happens on the day a change goes wrong.

This is the metric your board actually understands without translation, because it maps directly onto customer impact and onto the incident language your support organization already uses. It is also the one that most reliably exposes whether your on-call setup is real or theatrical. A team with genuine observability and a rehearsed rollback path recovers in minutes. A team without one recovers in however long it takes to wake up the person who wrote the service. Hope is not a runbook.

Never Report One Side Without the Other

The pairing is not a stylistic preference. It is the entire reason the framework works, and the last two years of research have made the point better than any argument I could construct.

DORA’s 2024 report found that AI adoption “significantly increases individual productivity, flow, and job satisfaction” while it “negatively impacts software delivery stability and throughput.” The report’s own estimate was that a 25% increase in AI adoption came with roughly a 7.2% drop in delivery stability and about a 1.5% drop in throughput. Then the 2025 report, drawn from nearly 5,000 technology professionals and more than 100 hours of interviews, found the throughput relationship had flipped positive. The stability relationship stayed negative. Ninety percent of the people surveyed now use AI at work, and more than 80% believe it made them more productive, which is the pair of numbers every vendor deck quotes at you. The finding nobody quotes sits alongside it. Thirty percent report little or no trust in the code it writes for them.

Read those two years together and the conclusion writes itself. Throughput went up. Instability went up alongside it, in both years, without exception.

If your 2026 delivery chart shows lead time falling and you have no instability line next to it, you have not proven your team got faster. You have proven your team got faster at something, and the something is unspecified. DORA’s own framing for this is that AI amplifies whatever is already there, and I would extend that to measurement generally. A one-sided metric amplifies whatever story you already wanted to tell. Yours included.

Show me the data on both sides or I cannot tell you whether your org is healthy.

Now the Two That Mislead

Both of the metrics in this section come out of the same instrument. That instrument is the estimate, and the estimate is the one number in your entire delivery system that a human being sets by hand, in advance, while under social pressure from the people who will later grade them on it. Set by hand. Graded later.

Story-Point Velocity

Points completed per sprint. The most reported engineering number in the industry and one of the least informative.

Three separate problems stack here. It is not comparable across teams, because a five on one team is a two on another, and there is no conversion table. It has no denominator anyone outside engineering recognizes, so it cannot be ranked against a marketing program or a warehouse lease in the same spreadsheet. And it inflates under observation, which is the part nobody says out loud in the retro. Once a team learns that rising velocity is what leadership rewards, estimates drift upward. Nobody decides to do this. It happens through a hundred small acts of reasonable caution that each look defensible in isolation and that collectively make your trend line meaningless within two quarters. Two quarters. Reliably.

Here is the part that surprises people. Open the November 2020 Scrum Guide and search it. The word “velocity” does not appear. Not once. Neither does “story points.” The framework everyone credits for these metrics stopped naming them, and the field kept reporting them anyway.

Sprint Completion Rate

Also called the say-do ratio. The percentage of committed sprint items actually finished.

Executives love this one because it sounds like accountability, and I have handed it over myself when a board wanted something quantitative before the end of the week. It measures forecasting conservatism. Nothing else. A team can raise its completion rate from 68% to 97% in two sprints without shipping a single additional thing, simply by committing to less, and the incentive to do exactly that is overwhelming once the number is on a slide with somebody’s name attached. Every time.

There is a deeper problem with it. The 2020 Scrum Guide attaches the Sprint Backlog’s commitment to the Sprint Goal, not to the item list, and states plainly that scope “may be clarified and renegotiated with the Product Owner as more is learned.” Completion rate measures adherence to the list that was always meant to be renegotiable. I wrote at length about what an honest version of that contract looks like in the sprint plan that acts like a contract, and none of that argument requires reporting completion percentage upward. Estimates as informed commitments inside the team, delivery data outside it. Two different audiences, two different instruments.

None of this is new. The research community settled it a while ago, and the industry never caught up.

Nicole Forsgren, Margaret-Anne Storey, and four co-authors published the SPACE framework in ACM Queue in February 2021. Their opening claim is blunt. Developer productivity “is about more than an individual’s activity levels or the efficiency of the engineering systems relied on to ship software, and it cannot be measured by a single metric or dimension.”

Five years on. Most engineering slides still carry exactly one.

What to Instrument This Month Without Buying Anything

You do not need a platform for the first pass. You need four queries and a spreadsheet, and if a vendor tells you otherwise, ask them which of the four they cannot compute from your existing Git history.

Start with deployment frequency, since your CI system already logs every deploy with a timestamp. Count them by week for the last twelve weeks and plot it. That takes an afternoon.

Change lead time is next, and it is the one with real work in it. Join each production deploy back to the commits it carried, take the median gap, and resist every impulse to use the mean, because one abandoned branch that merged after four months will wreck an average and tell you nothing true about your team. Then segment it. The segment holding the most time is where you go first.

Change fail rate needs one piece of discipline you probably do not have yet, which is a consistent tag on rollback and hotfix deploys. Add the tag, wait a month, then divide. Do not try to reconstruct it retroactively from memory. I have seen two teams try and both produced a number they could not defend when questioned. Do not be the third.

Recovery time comes out of your incident tooling if the incidents are logged, and out of a shared document if they are not. A shared document is fine for a quarter. It is not fine for a year. Set a reminder.

One rule holds all of this together. Report by team, never by individual. The moment a delivery metric gets attached to a person’s name, you have converted a diagnostic into a performance-review instrument, and it will start lying to you inside a single sprint. KORE1 wrote up the free three-test version of the broader diagnosis as an engineering velocity assessment if you want to pair the delivery data with the clarity questions in the same week.

When the Constraint Is a Seat, Not a Process

Sometimes you run all four numbers and the picture is unambiguous in a direction nobody wanted. Lead time is dominated by review latency because two people are qualified to approve changes in the payments path and both are already underwater. Recovery time is long because the only engineer who understood the integration layer left in March. That is not a process problem you can retro your way out of. That is a hiring problem.

Before you conclude that, rule out the other explanation. A team that is simply exhausted will post bad numbers across all four for reasons that have nothing to do with capability, and hiring into that situation makes it worse rather than better. The separate diagnostic for that is how to tell if your engineering org is actually slow or just tired, and it is worth thirty minutes before you open a req.

If it does resolve to a seat, hire for the specific bottleneck the data named, not for the generic title. KORE1 has placed senior engineering talent for more than twenty years across 30-plus U.S. metros and holds a 92% twelve-month retention rate on those placements, which is the number that matters when the role you are filling is the one your recovery time depends on. Their engineering practice works on contract, contract-to-hire, and direct hire. If you would rather have someone else measure it first, they also staff a two-week engineering velocity diagnostic that ends in a written verdict naming the constraint.

Where This Argument Usually Gets Pushback

Our leadership has tracked velocity for six years. Do I really have to kill it?

Do not take it away. Add the four delivery metrics alongside it for one quarter and let the two charts disagree in public.

Removing a number people trust makes you look like you are hiding something, even when you are right. Running both is slower, and it works, because within a quarter somebody in the room will notice that velocity rose while lead time did not move and ask why. Let them ask. The question lands differently coming from a CFO than from you, and by then the delivery data is already the thing everyone is looking at.

We deploy once a month because we are regulated. Do these metrics apply to us?

They apply more, not less. Regulated environments accumulate handoff time, and lead time segmentation is the only thing that shows you which handoffs are compliance and which are just habit.

Most of my career has been in mortgage and lending platforms, so I get this question constantly. What I have found almost every time is that a portion of the delay genuinely belongs to the regulator and a much larger portion belongs to a process somebody built around the regulator in 2019 and nobody has revisited. Measure the segments, and the distinction becomes obvious. Then argue about the habit. You may not be able to move deployment frequency much. You can almost always move the seven days sitting between approval and merge.

Which one do I put on the board slide if I only get room for one?

Change lead time, in days, with a median and a trend. It is the metric a non-technical director can interpret without a glossary, and it moves when real improvement happens.

Then put change fail rate in the footnote, in smaller type if you have to. One line. It costs you nothing, and it is the reason the headline number gets believed.

Will AI coding tools improve these numbers?

Throughput yes, stability no, based on two consecutive years of DORA data. Expect lead time to fall and change fail rate to rise at the same time.

That combination is exactly why you need the pairing before you roll the tools out rather than after. Set your instability baseline first. Otherwise you get six months in, quality complaints start arriving from support, and you have no way to tell whether the tooling caused it or whether the same drift was already underway before you signed anything.

How long before the numbers are actually trustworthy?

Six to eight weeks for deployment frequency and lead time. A full quarter for change fail rate, because you are building the tagging discipline while you collect.

The first four weeks of any of these will look strange, and you should not act on them. Deploy counts will be lumpy. Lead time will show outliers you cannot explain until you go read the specific pull request, which you should do, because that exercise teaches you more about your own delivery system than the aggregate ever will. Somewhere around week six the shape stabilizes. That is when you start reporting it.

Measure the Handoff, Not the Effort

Every metric in the misleading column measures how hard your team worked. Every metric in the predictive column measures how quickly work moved between people and systems.

Those are not the same measurement. Effort has never been your constraint. In twenty-five years I have met perhaps two engineering teams that were genuinely not trying hard enough, and several hundred whose work was sitting in a queue nobody was measuring while everybody in the building assumed the problem was capacity and quietly started drafting a headcount request.

Open your last board deck. Find the engineering slide. Read it honestly. If every number on it was calculated inside a planning tool, you are reporting effort, and the next hard question you get in that room will be one you cannot answer.

If you want to talk through which four you can actually instrument this quarter, or what to do when the data says something your exec team will not want to hear, connect with me on LinkedIn. If the constraint turns out to be a seat rather than a process, talk to a recruiter at KORE1 about what that hire actually needs to look like.

Related reading: The Clarity Stack: 3 Reasons Engineering Velocity Stalls, How to Tell If Your Engineering Org Is Actually Slow (vs. Just Tired), and The Hallway-Decision Problem.