CodeKuduCodeKudu
Log inSign up

Engineering metrics glossary

Plain-language definitions for delivery and flow metrics—especially those you see around DORA, pull requests, and engineering analytics—with honest caveats about measurement and misuse.

6 terms · Updated reference, not benchmarks.

Delivery and DORA

Change failure rate
Change failure rate is the percentage of production changes that cause degraded service or need remediation; the hard part is agreeing what counts as a failure.
Deployment frequency
Deployment frequency is how often your organization successfully ships to production; it reflects batch size and release capability more than raw coding output.
Lead time for changes
In the DORA framework, lead time for changes is the time from a commit reaching the mainline to that change running successfully in production—though teams adapt the exact boundaries.
Mean time to recovery (MTTR)
Mean time to recovery averages how long it takes to restore service after a failure; scope (what counts as “recovery”) must be defined with your incident process.

Flow and pull requests

Cycle time
Cycle time is the elapsed time work spends moving through your delivery pipeline—from start to done—though exact start and end points depend on your tool and process.
Throughput (and work in progress)
Throughput is how much work your system of delivery completes in a period; pairing it with work-in-progress (WIP) explains flow more than counting tasks alone.

Frequently asked questions

Why do two tools show different cycle times for the same team?

Cycle time and lead time depend on chosen start and stop events (board state, first commit, merge, deploy). Vendors use different defaults. Align on definitions before comparing numbers.

Are DORA “elite” thresholds goals we should hit?

DORA publishes research distributions across respondents; they describe industry snapshots, not universal targets. Regulatory, mobile, and enterprise contexts often look different from high-velocity SaaS web apps.

Should we use these metrics for performance reviews?

System metrics reflect workflow, priorities, and dependencies—not individual worth. If you use delivery data at all in reviews, pair it with qualitative context and avoid single-metric judgments.

Where can I learn more about developer productivity beyond delivery metrics?

See our article on developer productivity metrics for frameworks like SPACE and how delivery signals fit alongside satisfaction and quality.

Developer productivity metrics: what engineering managers should track