This guide is part of a course on How To Master DORA Metrics. You can find the intro to the course as well as links to other modules here.


In this module of the course, you’ll learn about the Lead Time for Changes DORA metric, what challenges commonly impact it, and how you and your team can help you overcome these issues.

Key takeaways from this module include:

  • Lead Time for Changes represents the average duration from beginning a change to your code base to the time the change’s code is released to production.
     
  • Understanding your cycle time is crucial to understanding — and improving — your Lead Time for Changes metrics. Composed of four-time stages (coding time, pickup time, review time, and time to deploy), cycle time helps you quantify the time an engineering task takes to move through production to deployment.
     
  • Causes of a poor Lead Time for Changes metric include development bottlenecks, a lack of automation, and poor communication, among other challenges. Using continuous merge, CI/CD pipelines, and scheduling regular retrospectives can mitigate these concerns.

Introduction

Lead Time for Changes refers to the average duration from beginning work on a code base change to releasing that change’s code to production. 

The majority of your lead time, and the most crucial phase of the software development and deployment process, is cycle time. Cycle time zooms in on the more quantifiable time for an engineering task to move from initial code commit to production deployment. 

Within cycle time, four discrete stages are critical to isolate and track individually: 

  • Coding time — The time an individual contributor spends writing the necessary code to complete the engineering task
  • Pickup time — The time between opening a pull request (PR) and beginning code review
  • Review time — The time between the initial code review and a pull request being approved by the team and merged for release to production
  • Time to deploy — The time it takes from merging the code change to its release in production

As software teams vary widely in the time they spend on each stage of cycle time, it’s important to gather discrete metrics for each stage to identify bottlenecks and areas for improvement in your delivery process. 

Understanding and optimizing cycle time

Cycle time is the most critical aspect in tracking the delivery time of new software features and updates, measuring team efficiency, and improving the predictability of project timelines. Our DORA Metrics dashboard lets you track the various stages of cycle time by interfacing with your version control system to display individual metrics for each phase.

"Cycle time is an engineering super metric" 

- Ori Keren, co-founder and CEO of LinearB

The ability to compare your team’s cycle time metrics with industry-standard engineering benchmarks helps identify areas for improvement to your platform or processes. 

Optimizing the predictability of your team’s delivery and release times allows engineering and product leadership to create more accurate project timelines, establish realistic go-to-market expectations for stakeholders, and boost the morale of development teams by reducing the likelihood of delays and missed deadlines. 

Why you should care about Lead Time for Changes

Lead time is the most vital metric to target when optimizing your team’s software development cycle. It is directly related to your business’ product delivery and go-to-market speed. A consistent and predictable lead time enables you to create accurate project timelines and keep your commitments to stakeholders.

It also reflects your team’s efficiency and morale: Greater confidence in their ability to deliver on-time code changes leads to happier team members and reduces the likelihood of burnout.

Common issues affecting Lead Time for Changes

Let’s discuss some common issues that can impact your Lead Time for Changes metrics.

Bottlenecks in the development pipeline

Identifying bottlenecks in your development pipeline is the first step in improving software delivery efficiency. Bottlenecks to watch for include:

  • Coding time — If your team’s average coding time is higher than the industry norm, it could indicate an issue at the project management level, where tasks aren’t broken into sufficiently manageable work units. It could also indicate a lack of clarity in defining task requirements or a need to diversify your team’s collective skillsets, seniority, or specialization levels. 
     
  • Pickup time — A high pickup time indicates a breakdown in communication within or between teams and can also indicate work overload. If developers have too many tasks in flight to begin reviewing each other’s code promptly, this will adversely affect pickup time and is a potential indicator of burnout. 
     
  • Slow code reviews — If your team’s code reviews exceed the industry average, they might be struggling with poorly scoped project management tasks. They might encounter bloated, difficult-to-review pull requests or fail to identify the team member with the most applicable project or domain knowledge to review specific code base changes. 
     
  • Deployment delays — A high average time to deploy could indicate bottlenecks in your testing/QA process or a lack of automation within your deployment approach.

Inefficient processes or lack of automation

The code pickup and review process are often two of the software development cycle’s most manual and inefficient phases. Once a pull request is opened, the code author must notify their teammates that it needs review. If they’re unsure about finding the most appropriate reviewer for their changes or their teammates are busy with other work, their pull request can sit in the pickup phase for quite some time.

Code reviews can also cause delays when pull requests are too long or complex, or there is a failure to select the proper expert for the review. At the same time, smaller, safer changes can pile up in the queue. Such changes could have been merged quickly without the burden of context switching to another more involved review.

Communication challenges within and between teams

While communication about pull requests and review processes can create issues for teams, there is even greater inefficiency for cooperating teams working on different sprint cycles, deadlines, and meeting schedules. Without a system of workflow automation to standardize communications, messages can go unread, necessitating multiple follow-ups to get a pull request moved from pickup to review. 

Changing requirements

Some degree of change concerning project requirements is inevitable in software development. However, constant and unpredictable change will lead to development inefficiency, frustration, and burnout within your teams.

There’s a symbiotic relationship between lead time and change requirements, as teams with quicker lead times can adjust more agilely to necessary changes. Still, you need to balance change and stability to maintain faster lead times.

Solutions to optimize cycle time

The good news is that you can address these common issues by improving your team’s automation processes, increasing communication, and performing regular retrospectives.

Use CI/CD and Continuous Merge

Continuous integration/continuous delivery (CI/CD) and continuous merge help you streamline development processes. 

In continuous integration, you merge code into a source repository in an environment where you can configure automated tests and build phases to run consistently and reproducibly. Then, with continuous delivery, code is automatically pushed through various staging and production deployment environments up to its final release. 

Just as CI/CD automates as many components as possible in a software release’s development, testing, and deployment phases, continuous merge streamlines the often manual and typically inefficient process of moving code through the pull request, review, and merge phases. 

Continuous merge works to resolve this issue by allowing code authors to provide context in the form of valuable metadata, such as estimated time to review, complexity of the code, and a request for expert reviews by indicating which section of the code base they’re working with. 

A continuous merge system can then prioritize code for review in the team’s queue so that less significant and lower-risk changes are merged more quickly, and the right team members get paired as reviewers on a pull request. These strategies reduce time spent on each engineering task in the pickup and review phases of your team’s cycle time and can be implemented seamlessly with gitStream. You can use gitStream’s programmable workflow features to improve your team’s code review process and optimize cycle time by creating automations to auto-merge safe changes and small fixes and approve pull requests from trusted teams.

Use engineering metrics benchmarks for targeted improvement

With a metrics platform, you have up-to-the-minute access to your team’s performance level for the various stages of cycle time compared to industry competitors. With this insight into your engineering benchmarks, you can target specific phases of cycle time for improvement and increase your performance across cycle time as a whole.

Improving your team’s pickup time positively affects review time, as longer pickup times for pull requests correlate directly with longer review times. You can use programmable workflow tools to reduce pickup and review time by adding estimated time to review labels to pull requests (PRs), assigning the right reviewer, and creating real-time alerts on a pull request's state. Tracking these metrics benchmarks also encourages your team to make smaller code changes in their PRs, a best practice in software delivery that results in demonstrable improvements across all DORA metrics. 

Streamline communication

Another strategy for improving cycle time metrics is streamlining communications within and across teams. Use automation tools that integrate various aspects of your toolchain, such as your messaging and communications platforms. 

You can streamline communication with tools like Slack, Microsoft Teams, and similar collaboration solutions to support real-time check-ins. Additionally, you can schedule regular sync-ups to ensure that everyone on the team is up to date on current projects, project progress, and development hiccups.

Schedule regular retrospectives

Create a culture of continuous improvement by scheduling regular retrospectives. In these retrospectives, your team can work collaboratively to identify and address bottlenecks by analyzing past and present development practices.

Practical steps to take action today

Below are some steps you can take today to improve your cycle and lead times:

  • Audit current development processes to identify time-consuming steps. Search for areas where bottlenecks frequently appear and center efforts on mitigating those issues.
     
  • Implement workflow automations that target major bottlenecks. Once you’ve identified what needs attention, leverage automation tooling to ensure event-driven tasks are executed as soon as possible and prevent introducing human error during manual work.
     
  • Gather metrics and key performance indicators (KPIs) related to cycle time for data-driven improvements. Use these KPIs to help you identify what is — and isn’t — benefiting your cycle time. 
     
  • Encourage a culture of continuous improvement within the team.

Long-term benefits of reducing cycle time

Identifying and addressing common issues and bottlenecks to reduce your team’s lead and cycle time produces numerous long-term benefits:

  • Increased customer satisfaction due to timely releases.
     
  • Enhanced team collaboration and reduced burnout.
     
  • Reduction in context switching with quicker reviews and less time spent on reviews.

Lead time analytics with LinearB

LinearB Metrics provides all the tools you need to accurately track and calculate your team’s cycle time through its project management and source code management integrations, letting you display, analyze, and compare this metric against industry benchmarks. 

gitStream’s estimated time to review features help reduce pickup and review time overall. Additionally, WorkerB’s goal-setting and notification features improve software engineering efficiency at the individual contributor and team levels.

To use LinearB to view historical data on each phase of your team’s cycle time, refer to our DORA metrics dashboard documentation. 

Summary

Now that we’ve explored the importance of tracking lead and cycle time and strategies for improving them, let’s turn to the next DORA metric: Change Failure Rate.

As we work through these metrics, be sure to get free DORA metrics to measure your organization against industry standards. Then, use gitStream to improve software engineering efficiency.