Engineering Productivity Metrics

DORA Deployment Frequency Tiers

The DORA (DevOps Research and Assessment) State of DevOps report classifies teams by deployment frequency:

Tier	Deployment Frequency
Elite	Multiple times per day (on demand)
High	Once per day to once per week
Medium	Once per week to once per month
Low	Once per month to once every 6 months

3.2 per day = multiple deployments per day = Elite tier.

Important context: High deployment frequency is only a positive signal when combined with low change failure rate and fast MTTR. Deploying frequently with a 30% failure rate is not elite performance.

Professional phrasing:

• "We're in the elite tier for deployment frequency."
• "Our deployment frequency is [X] per day — above the industry median."

Lead Time for Changes — definition and benchmarks

Lead time for changes = the time from a code commit (or code merge) to that code running in production.

DORA tiers:

Tier	Lead Time
Elite	Less than 1 hour
High	1 day to 1 week
Medium	1 week to 1 month
Low	1 month to 6 months

4.5 days = within the 1 day to 1 week High performer range.

Professional phrasing:

• "Our lead time is 4.5 days — in the high performer band."
• "We're working to reduce lead time by improving our CI pipeline."
• "Lead time spiked this sprint due to the infrastructure migration."

Sprint velocity — describing it with nuance

Velocity is not simply good-higher/bad-lower. The professional interpretation acknowledges multiple explanations:

• Genuine throughput increase: the team worked more efficiently
• Estimation inflation: stories were estimated more generously (point inflation)
• Simpler sprint composition: more small tasks, fewer large complex ones
• Team size change: more people on the team this sprint

The 10.5% calculation: (42 - 38) / 38 × 100 = 10.5% above the 4-sprint average.

Professional velocity vocabulary:

• "Velocity was [X] points — [above/below] our [N]-sprint rolling average of [Y]."
• "Velocity variance is within normal bounds."
• "The velocity spike may reflect improved flow or estimation changes — we'll watch the next sprint."

Change Failure Rate (CFR) — DORA benchmarks

Change failure rate = % of deployments that cause a production incident, rollback, or hotfix.

DORA CFR tiers:

Tier	Change Failure Rate
Elite	0–5%
High	5–10%
Medium	10–15%
Low	15–45%+

8% = High performer tier — above average but not elite.

Context matters: A team deploying 10 times per day with 8% CFR has more actual failures than a team deploying once per week with 8% CFR. CFR must always be read alongside deployment frequency.

Professional phrasing:

• "Our CFR is 8% — in the high performer range. We're working to push it below 5%."
• "The change failure rate spiked this month — we'll review our pre-production testing coverage."

PR (Pull Request) Open Time — a lead time driver

PR open time is the time from PR creation to merge. It contributes directly to lead time for changes.

Why a high number is a concern:

• Bottleneck signal: PRs sitting open for days suggests review is under-resourced or not prioritised
• Merge conflict risk: long-lived PRs diverge from main, creating costly conflicts
• Flow interruption: developers waiting for review lose context and context-switch to other work
• Lead time inflation: directly adds to the commit-to-production timeline

Industry benchmarks:

• Elite teams: under 1 hour average PR open time
• High performers: same-day review (4–8 hours)
• 3.8 days: indicates meaningful review friction

Professional phrasing:

• "Code review turnaround is a bottleneck — average PR age is [X] days."
• "We've introduced a PR review SLA: all PRs reviewed within 24 hours."
• "PR queue depth has increased — we may need to redistribute review load."