What is lead time for changes?
Updated
Lead time for changes is the time it takes for a code commit to reach production and run successfully. One of the four DORA metrics, it measures the speed and efficiency of a delivery pipeline — from the moment a change is committed to when it is live — and is, alongside deployment frequency, one of the two throughput signals.
Note the precise scope: DORA measures from code committed to code running in production. This is narrower than the broader Lean idea of lead time, which starts when a request or idea is first raised. Being clear about where the clock starts is what makes the metric comparable.
What lead time for changes measures
Lead time for changes captures how long the delivery pipeline takes to carry a committed change to production. It reflects the health of everything between commit and release: build and test speed, review latency, approval steps, and the deployment process itself. A short lead time means a developer can get a change into users' hands quickly; a long one means value sits in a queue.
It is one of DORA's two speed metrics, paired with deployment frequency. Together they describe throughput — how fast and how often a team delivers — while change failure rate and time to restore describe stability. Reading them as a set keeps a team from optimizing raw speed at the expense of reliability.
Where the clock starts and stops
The DORA definition is deliberately specific: the clock starts at code committed and stops at code successfully running in production. That excludes the fuzzy upstream time — grooming, prioritization, and design — because those vary enormously by organization and are hard to measure consistently. Starting at commit gives a clean, repeatable signal about the delivery pipeline itself.
This scoping is what separates lead time for changes from two adjacent terms teams often confuse it with. Getting the boundaries right is the difference between a metric you can trust and one that quietly measures different things on different teams.
| Term | Clock starts | Clock stops |
|---|---|---|
| Lead time for changes (DORA) | Code committed | Change running in production |
| Cycle time | Work started on the change | Change delivered or merged |
| Lead time (Lean / product) | Request or idea raised | Value delivered to the customer |
What drives long lead times
When lead time for changes is high, the bottleneck is almost always in the path between commit and production rather than in writing code. Slow or flaky test suites, long-lived branches, batching many changes into infrequent releases, manual approval gates, and heavyweight deployment processes all add queue time. Large changes are a common culprit: the bigger the batch, the longer the review and the higher the risk, which slows everything downstream.
The usual levers to shorten it are smaller, more frequent changes; faster and more reliable automated testing; trunk-based development to avoid long merge divergence; and automated deployment to remove manual handoffs. Because these same practices tend to lower change failure rate rather than raise it, improving lead time and stability together is the expected outcome, not a trade-off.
How to measure it well
Compute lead time for changes from your version control and deployment systems: for each change, take the timestamp of the commit and the timestamp of the production deployment that carried it, and measure the elapsed time. Because the distribution is usually skewed by a few slow outliers, report the median rather than the mean, and watch the trend over time instead of a single reading.
As with the other DORA metrics, DORA sorts teams into performance tiers rather than publishing one universal target to hit. The useful comparison is against your own history: a falling median lead time, paired with a stable or improving change failure rate, is the signal that the delivery system is genuinely getting faster rather than just cutting corners.
Frequently asked questions
How is lead time for changes measured?
For each change, measure the elapsed time from the code commit to the production deployment that carried it, using data from version control and the deployment pipeline. Because the distribution is skewed by slow outliers, report the median rather than the mean and track the trend over time.
What is the difference between lead time and cycle time?
In DORA, lead time for changes runs from code committed to running in production. Cycle time typically runs from when work on a change actually starts to when it is delivered or merged. The broader Lean sense of lead time starts even earlier, when a request or idea is first raised. The key is being explicit about where the clock starts.
What is a good lead time for changes?
There is no single universal target. DORA groups teams into performance tiers, with the strongest teams delivering committed changes to production far faster than the weakest, but the meaningful measure is your own trend. Falling median lead time alongside a stable or improving change failure rate is the healthy pattern.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.