Module dora_metrics 

The DORA Metrics Framework

The DORA metrics come from the DevOps Research and Assessment programme, later published as the book Accelerate, which surveyed tens of thousands of engineering professionals to find which delivery practices correlate with organizational performance. Four metrics, paired two and two: deployment frequency and lead time for changes measure speed; change failure rate and failed deployment recovery time measure stability. The framework’s central finding is that elite performers are fast and stable simultaneously — speed and safety do not trade off against each other the way intuition suggests.

Formula

Deployment frequency         = deployments / days
Lead time for changes        = deploy time − first commit time
Change failure rate (%)      = (failed deployments / total deployments) × 100
Failed deployment recovery   = restored time − detected time (never the deploy event)

Why it matters

DORA measures the pipeline, not the value flowing through it: a team can post excellent DORA numbers while its actual output has quietly drifted toward rework, a gap this book’s Flow Framework chapters are built to surface and DORA cannot see. Used within that bounded scope, DORA gives large organizations a consistent, comparable measure of pipeline mechanics across many teams — genuinely valuable for prioritizing platform investment, provided all four metrics are reported together and never applied to individual performance reviews.

Example

A platform team’s change failure rate falls from 25% to 8% across 100 production deployments a year, a stability improvement that DORA’s pairing discipline insists on measuring alongside any speed gain, never in isolation.

use software_engineering::dora_metrics::{
    change_failure_rate_percent, deployment_frequency_per_day,
    lead_time_for_changes_hours, failed_deployment_recovery_time_hours,
};

let cfr_before = change_failure_rate_percent(25.0, 100.0).unwrap();
let cfr_after = change_failure_rate_percent(8.0, 100.0).unwrap();
assert_eq!(cfr_before, 25.0);
assert_eq!(cfr_after, 8.0);
assert!(cfr_after < cfr_before);

// 2 deployments/day, a 6-hour lead time from first commit to production,
// and a 1.5-hour recovery from detection to restoration.
assert_eq!(deployment_frequency_per_day(14.0, 7.0).unwrap(), 2.0);
assert_eq!(lead_time_for_changes_hours(0.0, 6.0), 6.0);
assert_eq!(failed_deployment_recovery_time_hours(10.0, 11.5), 1.5);

Pitfalls

• Treating DORA as the whole picture of delivery health — it is silent on what kind of value is being delivered; pair it with flow distribution.
• Reporting only the speed half — defeats the framework’s central finding that speed and stability move together in high performers.
• Using DORA metrics in individual performance reviews — breaks the framework’s statistical validity and invites gaming.
• Comparing teams with inconsistent definitions of “deployment,” “change,” or “failure” — produces comparisons that look fair but are not.
• Self-reported DORA numbers instead of pipeline-instrumented ones — reintroduces exactly the bias the framework was designed to eliminate.

Sources

• Chapter 2.10, The DORA metrics framework.
• Forsgren, Nicole, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (2018).

Topic doc: software-engineering-metrics/locales/en-001/chapters/02-10-the-dora-metrics-framework.md

Functions

change_failure_rate_percent

Change failure rate: the percentage of deployments that caused a failure requiring remediation, a rollback, a hotfix, or an incident.

deployment_frequency_per_day

Deployment frequency: how often a team successfully releases to production.

failed_deployment_recovery_time_hours

Failed deployment recovery time (often shortened to MTTR): how long it takes to restore service once a deployment causes a failure.

lead_time_for_changes_hours

Lead time for changes: the time from a code change’s first commit to its successful deployment in production.