Understanding and improving lead time for changes

What is the lead time for changes?

Lead time for changes measures the average duration for a software change to move from check-in to successful deployment in your production environment.

Unlike productivity metrics that measure the quantity of work done in a change, such as counting lines of code, lead time for changes evaluates the speed of the process. It measures how quickly a team can review, test, and deploy a change by averaging the time across multiple deployments. This assessment encompasses all stages of the DevOps pipeline, providing a comprehensive view of the team’s efficiency in delivering software updates.

Lead time for changes is one of the DORA (DevOps Research and Assessment) metrics, a set of four key metrics that measure the performance of software developers. These metrics gained popularity through the book Accelerate: The Science of Lean Software and DevOps.

Change lead time differs from another DORA metric, deployment frequency. While deployment frequency measures how often new features or bug fixes are shipped within a specified period, lead time for changes explicitly measures the efficiency of the development and deployment processes. Deployment frequency gauges overall productivity, whereas lead time for changes focuses on process efficiency.

Lead time for changes also differs from two other similar-sounding metrics:

• Lead time measures the duration from a customer request to the start of feature development. Unlike lead time for changes, which focuses on the time from code check-in to deployment, lead time encompasses the initial stages of identifying and planning a feature.
• Cycle time measures the duration it takes to deliver a change throughout the entire software development lifecycle (SDLC), from customer requests through design, development, and deployment. In contrast, lead time for changes focuses explicitly on the latter part of this process, from code check-in to deployment.

How to calculate lead time for changes

1. Pinpoint key stages: First, determine your lead time’s start and end points. Typically, this process begins when a developer commits code for a change (such as adding a new feature or fixing a bug) and concludes when the change is deployed in production.
2. Collect data: Gather timestamps for each stage of the development process. Use tools like Jira, GitHub, or GitLab to track when the team creates a change request, starts development, finishes the code review, and deploys the change.
3. Do the math: Subtract the start and end times to find the total lead time.

Lead time for changes example

Imagine your team receives a change request to add a new login feature to your application on May 1st at 9:00 AM.

• Change request creation: May 1st, 9:00 AM
• Development starts: The developer begins working on the feature right away. By May 1st, 6:00 PM, the initial code for the login feature is ready.
• Code review: The code review process starts at 9:00 AM on May 2nd and is completed by noon the same day.
• Testing: Testing begins immediately after the code review. The QA team tests the new login feature by checking functionality, security, and user interface compatibility. Testing is completed by May 3rd at 9:00 AM.
• Change deployment: The team deploys the change on May 3rd at 3:00 PM.

Adding these intervals together gives you a total lead time of 54 hours—just over two days from the change request to being live in production. This detailed tracking helps your team understand the efficiency of your processes and identify any stages that may need improvement.

Handy tools to measure lead time

You don’t have to do all this manually. Several tools can help automate the tracking and calculation of lead time for changes:

• Jira: This integrates with your development workflows to track creation and deployment changes.
• GitHub/GitLab: Both offer built-in tracking for pull and merge requests, including timestamps for various stages.
• CI/CD tools: Tools like Jenkins, CircleCI, and Azure DevOps monitor and report on deployment times.
• DX: A single source of truth for engineering metrics and reporting, measuring DORA metrics as part of the DX Core 4.

Benefits of measuring lead time for changes

Lead time for changes can provide valuable insights into your development processes and help you identify any potential blockers to production. Here are some of the key benefits to understanding this metric:

Enhances predictability

Measuring change lead time helps teams better predict the time required to implement and deliver new features, leading to more accurate project timelines and planning.

Improves customer satisfaction

Organizations can deliver updates and features more consistently by understanding and optimizing lead time, resulting in a better customer experience and increased satisfaction.

Identifies process bottlenecks

Tracking lead time highlights areas where delays occur. This enables teams to identify and address bottlenecks in their development process, resulting in smoother workflows.

Facilitates continuous improvement

Regularly measuring lead time provides valuable data for ongoing process improvements, helping teams to implement changes that enhance efficiency and quality over time.

Supports data-driven decision-making

Having concrete data on lead times empowers managers and stakeholders to make informed decisions about resource allocation, process adjustments, and strategic planning.

How lead time for changes is included in the Core 4

Lead time for changes is one part of the Core 4 framework, which also includes deployment frequency, change failure rate, and mean time to recovery. Looking at lead time in isolation can be misleading—shortening lead times without improving failure rates or recovery speed, for example, only shifts the bottleneck elsewhere.

By combining all four metrics, leaders can diagnose delivery performance holistically:

• Lead time highlights process speed.
• Deployment frequency shows throughput.
• Change failure rate reveals quality.
• MTTR captures resilience.

Together, these metrics provide leaders with a balanced and actionable view of deployment health—essential for reducing waste, accelerating value delivery, and ensuring that improvements are sustainable.

You have lead time for changes data. Now what?

Lead time for changes serves as a diagnostic metric that reveals the health of the deployment pipeline. Elite teams achieve lead times under 4 hours, high-performing teams under 24 hours, while medium performers range from one day to one week. Use quarterly trends to identify the impact of process changes and tooling investments.

To drive daily improvements, break down diagnostic insights into specific improvement metrics:

• Track “time to first PR review” when code reviews consistently exceed 4-6 hours
• Monitor “test execution time” and “test flakiness rate” for extended testing cycles
• Measure “deployment success rate” and “rollback frequency” for manual deployment friction
• Survey developer satisfaction with deployment processes to connect system metrics with team experience
• Set team notifications for PRs awaiting review beyond threshold times

Avoid these common measurement mistakes

• Confusing lead time with cycle time: Lead time measures code commit to deployment, not the entire development process from requirements to delivery.
• Optimizing speed at quality’s expense: Rushing deployments increases change failure rates, ultimately consuming more engineering hours through incidents and rework.
• Ignoring contextual factors: A database migration naturally requires longer lead time than a UI update—segment analysis by change complexity.
• Measuring without acting: Simply tracking lead time without investigating underlying bottlenecks wastes the diagnostic opportunity.
• Missing the developer experience connection: Combine system metrics with DXI survey data to ensure process optimizations improve rather than degrade team satisfaction.

The role of AI in lead time improvement

The next evolution in productivity measurement is integrating AI impact measurement into traditional deployment metrics. AI coding assistants are beginning to reshape how quickly teams can move from code to deployment, with early studies showing 20–30% improvements in lead time.

AI accelerates lead time by reducing the time developers spend on initial code generation, boilerplate, and test scaffolding. This enables engineers to move more quickly from commit to review and from review to deployment.

In practice, pull requests are opened hours earlier, review cycles begin sooner, and small, incremental changes flow through the pipeline with less friction. These improvements align closely with the goals of Core 4 reporting, where reducing lead time is one of the most direct ways to reclaim wasted engineering hours.

Why measuring AI’s impact is more complex

But measuring AI’s impact requires more than just tracking faster commits. In some cases, AI can also increase rework by producing lower-quality code that lengthens review or testing stages. It can create new dependencies in developer workflows that affect satisfaction and cognitive load.

Without visibility into these dynamics, improvements in raw lead time numbers risk masking new inefficiencies elsewhere in the pipeline. This is why leaders need to pair system metrics with DXI survey data to fully understand how AI is changing both delivery speed and developer experience.

That’s why it’s essential to combine Core 4 metrics with AI impact measurement. This dual approach shows leaders not only where AI accelerates delivery, but also where hidden costs—such as increased review cycles, test flakiness, or reduced developer satisfaction—may offset perceived gains.

The result is a more accurate, balanced picture of how AI is reshaping delivery performance and what leaders can do to ensure those changes translate into real, sustainable productivity improvements. For a deeper dive into how to operationalize this, see DX’s research on measuring AI’s impact on engineering productivity.