Lead Time for Changes is a DORA metric and as such a core DevOps metric (and more broadly a core Agile delivery metric).
There are four DORA metrics popularised by the DevOps Research and Assessments (DORA) group of which Lead Time for Changes is one. The others are: Deployment Frequency, Change Failure Rate and Time to Recovery.
Lead Time for Changes is defined in the Accelerate book (which popularised the DORA metrics) as ‘the time taken to go from code committed to code successfully running in production”. As such it is very 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:
- Time to Review – From open to the first comment or review
- Time to Approve – From the previous stage to approved
- Time to Merge (Commit)/Close – From the previous stage to merge/close
- Time to Deploy – From the previous stage to deployed to production.
Whilst Lead Time for Changes focuses only on stages (3) and (4) above.
Example Lead Time for Changes chart – Plandek DORA metrics dashboard
The calculation of Lead Time for Changes requires surfacing data from CI/CD tools (e.g. Jenkins, CircleCI) and code repositories. This is most easily done via an end-to-end delivery metrics dashboard like Plandek (www.plandek.com).
Analysis of Lead Time for Changes – Breakdown and Filtering Options
Delivery metric dashboards like Plandek enable you to analyse delivery, engineering and DevOps metrics in a number of different ways.
Below is a selection of the options available to analyse DORA metrics such as Lead Time for Changes:
|Author||The individual who created the Pull Request (PR). Useful to filter down to a specific individual or individuals across many repos.|
|Participant||Any individual who took action on the PR (not including the Author). Great way to see who are the go-to team members for reviews etc.|
|Stage||The specific stage the PR has been through. Essential to understand where time is being spent on average across your completed PRs.|
|Repository||Allows you to see how Lead Time for Changes compares across repos and if PRs in particular repos take longer than others.|
|Ticket Issue Type||Based on ticket reference linking, you can gain a unique perspective on this metric based on any Ticket related field you have configured. In this case, you would be able to understand code cycle time based on the related ticket being a Story or Bug etc.|
Example Lead Time for Changes drill-down chart – Plandek DORA metrics dashboard
Related DORA metrics
Lead Time for Changes is one of four DORA metrics. As such it is often used is 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:
- Deployment Frequency (DF)
- Mean Time to Recover (MTTR)
- Change Failure Rate (CFR).
Key use cases
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 quickly develop.
Empirical data shows that Lead Time for Changes typically accounts for circa 30% of Cycle Time – so the PR process is very often a key source of ‘hidden’ delay.
Lead Time for Changes is particularly important for organisations looking to increase delivery velocity (reduce Lead Time) -e.g.:
- delivery organisations at an early stage of Agile DevOps maturity
- large scale delivery capabilities with distributed teams (onshore, offshore, contractor, inhouse) and potentially a higher turnover of engineering talent
- teams involved in strategically critical software delivery projects.
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 reducing pressure on the individuals themselves and at the same time reducing 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 1 month and 6 months.
Plandek is a global leader in software delivery metrics and analytics, recognised by Gartner as a top nine global vendor in their DevOps Value Stream Management Market Guide (published in Sept 2020).
Plandek works by mining data from toolsets used by delivery teams (such as Jira, Git, CI/CD tools and Slack), to provide end-to-end delivery metrics & analytics to optimise software delivery predictability, risk management and process improvement.
Plandek is based in London and works with clients globally to apply predictive data analytics and machine learning to deliver software more effectively.