Plans
Roles
Support
Customers
The complete Software Engineering Intelligence platform
Get the full suite of Plandek intelligence tools for actionable delivery insights at every level
Book Demo
PRODUCT OVERVIEW
USEFUL PAGES
Data-driven insights for engineering leaders
2025 Software Delivery Benchmark Report
Download Now
PRICING
ABOUT
ACADEMY
Solutions
Platform
Pricing
About
Academy
Your voice matters: Join the GenAI adoption conversation - contribute to our industry research.
Written by
Lead Time for Changes is a DORA metric and, as such, is also a core DevOps metric.
Lead Time for Changes is defined in Accelerate: The Science of Lean Software and DevOps (which popularised the DORA metrics) as ‘the time taken to go from code committed to code successfully running in production.’ It’s similar to the Code Cycle Time metric.
Code Cycle Time is a broader metric in that it provides insight into the different stages that a Pull Request goes through and the time to deploy. These stages are defined as:
Lead Time for Changes, however, only focuses on the final two stages listed above.
Lead Time for Changes | Plandek DORA Metrics Dashboard
Calculating Lead Time for Changes requires surfacing data from CI/CD tools (e.g. Jenkins, CircleCI) and code repositories. Plandek provides an intelligent and predictive dashboard that significantly reduces the time and effort this task requires.
Delivery metrics dashboards like Plandek enable you to analyse delivery, engineering and DevOps metrics in various interactive and customisable ways.
Below is a selection of the options available within Plandek to analyse DORA metrics, such as Lead Time for Changes:
Lead Time for Changes Drill-down | Plandek DORA Metrics Dashboard
Lead Time for Changes is one of four DORA metrics. As such, it is often used as part of a ‘balanced scorecard’ of agile delivery and DevOps metrics surfaced in real-time.
The other DORA metrics often closely associated with Lead Time for Changes are:
Lead Time for Changes is a very useful DevOps metric to help teams reduce their overall Lead Time and increase the velocity of software delivery.
The Pull Request process can become a key blocker in the overall delivery process as code awaits peer review. This may be because teams rely on a few key engineers to action the majority of Pull Requests, and hence bottlenecks develop rapidly.
Empirical data shows that Lead Time for Changes typically accounts for around 30% of Cycle Time. This means the PR process is very often a key source of ‘hidden’ delay.
Understanding and optimising Lead Time for Changes is particularly important for organisations looking to increase delivery velocity, such as:
Reducing Lead Time for Changes will reduce overall Lead Time and increase software delivery velocity. Empirical evidence shows that it is not uncommon to reduce Lead Time by 5-10% through tracking and effective management of Lead Time for Changes.
Detailed analysis will also reveal the engineers responsible for actioning the majority of PRs and can help Team Leads reduce the pressure on these key individuals. Thereby, the analysis will reduce pressure on the individuals themselves and, at the same time, reduce the ‘key-person’ risk within the software delivery capability.
According to the DORA 2018 Report, Elite performers have a Lead Time for Changes of less than 1 hour, and Low performers have a Lead Time for Changes that is between one month and six months.
Looking to learn more about the DORA framework? Why not take a look at these other related resources to expand your knowledge further:
Download
Free managed POC available.