Top 10 Engineering Productivity Metrics: DORA, DevEx and AI [2026]

The 10 Engineering Productivity Metrics

1. Deployment Frequency

Deployment frequency counts how often a team ships code to production, and it is the easiest of the five DORA metrics to read straight from a CI/CD pipeline.

The most common answer in DORA's 2025 survey was between once a week and once a month, given by 31.5% of respondents. Only 16.2% deploy on demand, several times a day.

A high number matters less than what it says about batch size. Teams that deploy daily ship small changes, and small changes are easier to review, test and roll back.

"Working in small batches" is one of the seven capabilities in the AI Capabilities Model that DORA published with its 2025 State of AI-assisted Software Development report, because AI tools amplify whatever batch size a team already works in.

• How to measure: successful production deploys per service per day or week, pulled from your deploy tool, not from merged PRs.
• Strong result: on demand. At the other end, 3.6% of DORA's respondents deploy less than once every six months.
• Watch out for: splitting one release into many trivial deploys to move the number. Read it next to change failure rate.

2. Lead Time for Changes

Fewer than one team in ten can take a committed change to production within an hour.

Lead time for changes measures that span, from commit to running in production, and in DORA's 2025 data the largest group, 31.9%, needed between one day and one week.

Long lead times rarely come from slow typing. They come from queues: a PR waiting for review, a build waiting for a test environment, a release waiting for a change board.

That is why lead time is best read as a total and then split into the stages in metrics 6 and 7, where the waiting shows up.

• How to measure: median time from the first commit in a change to its production deploy, per service. DORA's metrics guide defines each of the five terms.
• Strong result: under one day. In DORA's data, 24.4% of respondents reach it (the under-one-hour and under-one-day bands combined).
• Watch out for: averages. One stuck change skews a mean for weeks, so report the median and the slowest 10%.

3. Change Failure Rate

Change failure rate is the metric AI has made worse. It is the share of deployments that cause a failure in production, and the 2025 DORA report found that AI adoption "still increases delivery instability" even as throughput improves.

The year before, DORA estimated a 7.2% rise in instability for every 25% increase in AI adoption.

Telemetry tells the same story at larger scale.

Faros AI tracked 22,000 developers across 4,000 teams for its Q2 2026 AI engineering report: teams with high AI adoption completed 33.7% more tasks than low-adoption teams, but logged 242.7% more incidents per pull request.

In DORA's survey the most common change failure band was 8% to 16%, reported by 26% of respondents, and 5.9% said more than 64% of their changes fail.

• How to measure: deploys that needed a rollback, hotfix or incident response, divided by all deploys in the period.
• Strong result: under 1% for LinearB's elite tier; above 17% puts a team in its "needs focus" group.
• Watch out for: an incident process that only logs outages. Degraded performance and silent data errors are failures too.

4. Failed Deployment Recovery Time

This used to be called mean time to restore, and DORA has changed it twice. It was renamed to count only the time to recover from a failed deployment, not from any outage, and in 2025 it moved from the stability group into throughput.

A team that can roll back in minutes can afford to ship more often.

Recovery is where most teams do best. In DORA's 2025 survey, 21.3% restore service within an hour of a bad deploy and another 35.3% within a day, while 1% need more than six months.

LinearB dropped recovery time from its 2026 benchmarks altogether, saying the figure varied too much between organizations to compare.

• How to measure: time from the failed deploy being detected to the service running normally again, through rollback, fix-forward or feature flag.
• Strong result: under one hour, which usually means automated rollback and flags rather than faster debugging.
• Watch out for: the older MTTR. Many dashboards still blend infrastructure outages into it, which is not the same measure.

5. Rework Rate

Rework rate is the newest DORA metric and the one most teams are not yet tracking.

DORA defines it as "the ratio of deployments that are unplanned but happen as a result of an incident in production," in other words the patches a team ships because an earlier release broke something.

Together with change failure rate it forms DORA's instability factor.

The two instability metrics have almost the same shape. The 8% to 16% band is the most common for both, and rework runs slightly heavier in the bad tail: 22.7% of respondents report rework above 32%, against 18.4% for change failures.

A team with low change failure but high rework is often hiding failures as "planned" follow-up releases.

• How to measure: tag each deploy as planned or unplanned, and count unplanned deploys linked to a production incident.
• Strong result: 0% to 2%. LinearB uses its own rework definition, code rewritten soon after it ships, and puts elite teams under 3%.
• Watch out for: mixing the two definitions on one dashboard. Say which one a number uses.

6. Cycle Time

Cycle time is the metric I would put on a dashboard first, because it splits into stages a team can act on.

It runs from the first commit on a branch to its release, and LinearB breaks it into coding time, pickup time, review time and deploy time.

In its 2026 benchmark report, drawn from 163,820 contributors in 42 countries, the tiers look like this.

The stage that dominates is usually deploy, not coding. LinearB's elite line for coding time is under 54 minutes, while elite deploy time is anything under 16 hours, and a "needs focus" team takes more than 277 hours to deploy a merged PR.

If your cycle time is long, look at the release process before you look at the engineers.

• How to measure: per pull request, from first commit to production, with each of the four stages timed separately.
• Strong result: under 25 hours at the 75th percentile, LinearB's elite threshold.
• Watch out for: comparing individuals. Cycle time is a team and system metric; ranking people on it rewards cherry-picking easy tickets.

7. Review Pickup and Review Time

Code review is where AI-era pull requests pile up. Pickup time is how long a PR waits for its first reviewer, and review time runs from that first look to approval.

Faros AI's 2025 study of more than 10,000 developers found that teams with high AI adoption merged 98% more pull requests, while PR review time rose 91%. Code generation sped up; human review did not.

Google set the reference point years before AI coding tools.

Its study of about 9 million code changes found authors waited a median of under an hour for first feedback on small changes and about 5 hours on very large ones, with the whole review taking under 4 hours at the median.

Fewer than 25% of changes had more than one reviewer. If review is your bottleneck, our comparison of AI code review tools covers what can take the first pass.

• How to measure: PR opened (or marked ready) to first review comment, then first comment to approval, from your Git host's API.
• Strong result: pickup under 1 hour and review under 3 hours, LinearB's elite lines.
• Watch out for: rubber stamps. Fast approvals on 1,000-line PRs make this metric look great and change failure rate look terrible.

8. Pull Request Size

PR size is the cheapest leading indicator on this list. The median change at Google modified 24 lines, and LinearB's elite teams keep PRs under 100 code changes, while anything above 228 lands in "needs focus."

Small PRs get reviewed faster, fail less and roll back cleanly, so this one number moves metrics 3, 6 and 7 with it.

AI is pushing the number the wrong way. LinearB measured AI-assisted PRs at 2.6 times the size of unassisted ones, and accepted only 32.7% of AI-generated PRs against 84.4% of manual ones.

The old reviewer rule of thumb still applies: SmartBear's code review guidance says to review no more than 200 to 400 lines at a time. For quality signals beyond size, see our AI-generated code quality metrics.

• How to measure: lines added plus lines deleted per PR, excluding generated files, lockfiles and vendored code.
• Strong result: under 100 changes at the 75th percentile.
• Watch out for: stacked PRs that split one risky change into five dependent ones. Size drops; risk does not.

9. Developer Experience Index (DXI)

Developers spend about 16% of their time writing code, according to Atlassian's 2025 survey of 3,500 developers and managers. The other 84% is where developer experience metrics look.

The best known is DX's Developer Experience Index, a survey score built on the DevEx framework's three dimensions: feedback loops, cognitive load and flow state.

DX says in its DXI report that each one-point gain "correlates to 13 minutes per week of developer time saved," based on research with 40,000 developers across 800 organizations.

The DXI is the effectiveness pillar of the DX Core 4, next to diffs per engineer, change failure rate and the share of time spent on new capabilities. Atlassian agreed to buy DX for about $1 billion in September 2025, per its SEC filing.

Large companies outside the DX customer base tend to run their own surveys instead. SAP, for instance, publishes no developer experience scorecard.

Its public signal is the annual Developer Insights Survey, answered by 589 developers in 44 countries in 2026.

In the 2025 edition, about 74% said they were "very satisfied" or "satisfied" with development work on SAP, and SAP Community guidance for BTP extension teams points them to DORA metrics for delivery.

• How to measure: a quarterly survey of 10 to 20 questions on build speed, review waits, documentation and interruptions, paired with the system metrics above.
• Strong result: a rising score and a falling count of hours lost. In Atlassian's 2025 data, 50% of developers lost 10 or more hours a week to inefficiencies.
• Watch out for: surveys with no follow-up. Atlassian found 63% of developers say leaders do not understand their pain points.

10. Net AI Time Savings

In METR's July 2025 trial, 16 experienced open-source developers took 19% longer on real issues when AI tools were allowed, yet afterwards believed AI had made them 20% faster.

A follow-up in February 2026 with 57 developers pointed to speedups, but METR called its own new data an "unreliable signal" that likely understates the gain.

The lesson for measurement holds either way: self-reported AI savings are not evidence.

DX's AI Measurement Framework gives the cleanest formula. It tracks utilization, impact and cost, and its cost dimension includes "net time gain per developer," time saved minus AI spend.

GitHub's Copilot usage metrics API supplies the utilization side, from daily active users to PRs merged and median time to merge. The trend lines below show why the net figure matters more than the gross one.

• How to measure: hours saved per developer per week from a short survey, checked against cycle time and change failure rate for the same teams, minus license and token spend.
• Strong result: a positive net figure that survives the review and rework AI code creates. Our AI coding assistant statistics track adoption by tool.
• Watch out for: counting AI usage itself as output. Atlassian's 2026 data shows developers inflate usage when they think it is being watched.

Frequently Asked Questions

Are DORA metrics still the right engineering productivity metrics in 2026?

For delivery, yes, in their 2025 form of five metrics. They do not measure developer experience or AI payoff, which is why frameworks such as SPACE, DevEx and the DX Core 4 add survey data alongside them.

DORA has not published a 2026 State of DevOps survey report.

What tools track engineering productivity metrics?

LinearB lists DORA metrics from $29 per contributor a month. Swarmia is free for up to 9 developers, then $45. Haystack starts at $20 per member. DX, Jellyfish and Span quote on request.

Span positions itself on linking AI agent sessions to code and PRs, DX on survey-backed frameworks. Our guide to AI developer productivity tools covers the coding side.

Should you measure individual developer productivity?

Not with these metrics. DX marks diffs per engineer "not at individual level" and warns against tying targets or rewards to it. Use team-level numbers to find bottlenecks, and one-to-ones for individual performance.