Lead Time for Changes – DORA metrics

What is Lead Time for Changes?

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:

• 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

Lead Time for Changes, however, only focuses on the final two stages listed above.

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.

Breakdown and Filtering Options with Lead Time for Changes

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:

1. Author: The individual who created the PR. This is useful to filter down to a specific individual or individuals across many repos.
2. Participant: Any individual who took action on the PR (not including the Author). This is a great way to keep track of the go-to team members for certain sections of the Cycle.
3. Stage: The specific stage the PR has been through. This is essential to understand where time is being spent across your completed PRs.
4. Repository: This allows you to see how Lead Time for Changes compares across repos and if PRs, particularly repos, take longer than others.
5. 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 could understand Code Cycle Time based on the related ticket being a Story or Bug, etc.

Related DORA Metrics

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:

• 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 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:

• 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 talents
• teams involved in strategically critical software delivery projects

Expected outcomes

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.