Lead time for changes
The time from first commit to production deployment — a measure of how fast value flows through your delivery pipeline.
// Formula
// About this metric
Lead time for changes measures the elapsed time from when a developer first commits code to when that code is running in production. It is one of the four DORA metrics and measures software delivery speed — distinct from deployment frequency (how often) or change failure rate (how safely).
The DORA 2024 research classifies Elite teams as achieving lead times under one day, High teams at one day to one week, Medium teams at one week to one month, and Low teams above one month. Lead time has shortened significantly over the decade of DORA research as CI/CD adoption has increased.
Short lead time reduces the cost of defects (they are found faster), reduces inventory waste (less work-in-progress), and accelerates learning cycles (feedback from production reaches development faster). It requires fast CI pipelines, streamlined code review, automated deployment, and minimal manual approval gates.
Lead time is measured from first commit (not from story creation or ticket opened, which would be cycle time). The distinction matters: cycle time includes planning and refinement time; lead time measures purely the engineering delivery pipeline.
// Calculator
🧮 Calculator
// Benchmark
Source: DORA State of DevOps Report 2024
// When to use this metric
Use lead time to evaluate your CI/CD pipeline efficiency. If lead time is high, break it down by phase: time in code review, time in CI queue, time waiting for deployment approval. The bottleneck is usually visible in the phase-level breakdown.
Pair it with cycle time if you want to include the planning phase in your delivery measurement — cycle time is the upstream complement to lead time.
// Common pitfall
Lead time can look fast if you are measuring only the final commit-to-deploy step, ignoring the fact that a feature took three sprints of back-and-forth before a reviewable commit existed. Instrument from the first commit in a feature branch, not the merge commit — or compare lead time against cycle time to see whether the "invisible" pre-commit phase is hiding slow delivery.