Lead time for changes is one of the four DORA metrics: it measures how long a code change takes to travel from committed to running in production. A shorter lead time means faster feedback, smaller and safer releases, and quicker value for customers. This guide explains what it is, what counts as good, and how to start measuring it in Jira.

Lead time for changes is a throughput signal — one half of the speed side of the four DORA metrics. It pairs with deployment frequency to describe how fast a team delivers, while change failure rate and recovery time describe how safely.

What is lead time for changes?

It is the elapsed time between a change being committed to version control and that change being deployed to production. It deliberately measures the delivery pipeline — coding complete, review, integration, testing, release — rather than the time a request spends waiting in a backlog. That broader “idea to delivery” span is plain lead time, and the active-work portion is cycle time; we separate all three in cycle time vs. lead time.

Why lead time for changes matters

Long lead times usually hide a process problem: large batch sizes, manual deployment steps, slow reviews, or too much work in progress. Each of those lengthens the feedback loop between writing code and learning whether it works in production. Teams that shorten lead time tend to release smaller changes more often, which lowers the risk of any single release and makes failures easier to isolate.

What is a good lead time for changes?

A good lead time for changes is under one week, and the fastest teams ship in under one day. In DORA’s 2025 research the top 15% of teams get a change from commit to production in less than a day, only about 9% manage it in under an hour, and roughly a third of teams take between one day and one week. The 2025 report retired the old Elite/High/Medium/Low labels in favour of seven team archetypes, so treat these cut-offs as reference points, not grades. The more durable signal is your own trend: a lead time falling quarter over quarter, with less variation between changes.

How to measure lead time for changes in Jira

Jira measures the part of the journey that happens inside your workflow extremely well — when an issue moves to In Progress, how long it waits in review, and when it reaches Done. That gives you the in-workflow component of lead time as a reliable proxy.

For the full commit-to-production metric you also need two timestamps Jira doesn’t own: the commit (from Git) and the production deploy (from your CI/CD pipeline or a fix-version release date). The practical pattern is to combine Jira’s status history with a deployment marker — many teams use the fix version’s release date as the “deployed” timestamp until a CI integration is in place.

How to improve lead time for changes

• Shrink batch size. Smaller pull requests and stories move through review and testing faster.
• Limit work in progress. Less parallel work means less waiting and context-switching.
• Automate the pipeline. Automated testing and deployment remove the slowest manual steps.
• Attack wait time, not just work time. Most lead time is spent waiting in queues — reviews, approvals, hand-offs — not in active coding.

Measuring the Jira portion with Flow Metrics Charts

Our app, Time in Status, Cycle Time & Lead Time Reports, charts Lead Time and Cycle Time directly from your Jira data — measured from any start status to any end status — and lets you break the numbers down by epic, label or fix version and export them. A built-in Rovo AI agent reads each chart and points to where work is waiting. Full DORA support, including deployment-aware lead time for changes, is on our roadmap; the flow-time foundation is available today.

FAQ

Is lead time for changes a Jira metric? Partly. Jira measures the in-workflow portion accurately; the commit and deploy timestamps come from Git and your CI/CD system.

What’s the difference between lead time and lead time for changes? Lead time covers request to delivery; lead time for changes is the narrower commit-to-production window DORA tracks.

Is change lead time the same as lead time for changes? Yes. Change lead time and lead time for code changes are alternative names for the same DORA metric — the elapsed time from a commit landing in version control to that change running in production. Different tools label it differently, but the clock is the same.

What is the KPI for lead time? The KPI is the median lead time for the period, usually reported alongside a high percentile such as p85. State three things whenever you publish it: the clock (commit to production, for DORA), the statistic (median, not average — an average is dragged around by one stalled change), and the population (which repositories, services or issue types are counted). A KPI defined that precisely can be compared month to month; “our lead time is four days” on its own cannot.

What is lead time in a change management process? In ITIL-style change management, lead time is the elapsed time from a change request being raised to the change being implemented in production — so it includes the CAB approval wait, which the DORA metric excludes. If your team quotes a change-management lead time and a DORA lead time for changes, expect the first to be much longer; the gap between them is almost entirely approval and scheduling queue.

How do you calculate lead time for changes? For each deployed change, subtract the commit timestamp from the production-deploy timestamp. Then report the median (or a percentile like p85) across all changes in the period — a median resists the skew of one slow outlier, so it reflects your typical pipeline rather than your worst week.

How do I lower lead time for changes? Reduce batch size, limit work in progress, automate testing and deployment, and cut the queue and wait time between steps.

---

See your lead time in Jira: Try the app free · Learn more on divim.io

Part of our DORA series: DORA Metrics in Jira · Cycle Time vs. Lead Time