Lead time for changes vs cycle time for software developers

The ability to efficiently take an idea from a concept to a user-ready feature is a key workflow for software-centric businesses. Typically, this covers most of the software development lifecycle (SDLC), from requirement gathering through development, all the way to deployment and release. However, teams will vary greatly in effectiveness, with sizable differences between organizations when it comes to how fast teams can build and ship features.

‍

Peter Drucker's statement "You can't manage what you can't measure" is a reminder that you can't improve something if you can't measure it effectively. There are many relevant metrics you could track for software delivery. However, lead time for change and cycle time stand out as good candidates for teams looking to improve their overall delivery. These two metrics track similar things and often get mixed up. However, they have differences, and understanding them will help you measure, improve, and draw useful insights.

‍

In this article, you'll compare these two metrics. You'll see what key stages in software development contribute to them, their major influencing factors, and their limitations as a metric. Finally, you'll learn about what to look for in an effective report that measures these metrics and how to use those reports' insights to optimize your software delivery processes.

‍

Lead Time for Changes

Lead time for changes essentially tracks the time between the identification of a requirement and its fulfillment. This covers all of the activities performed by the software team to deliver a given feature, not just the developers.

With so many phases involving multiple team members and different software tools like Jira for managing requirements and GitHub for managing commits, testing, and deployments, it can be difficult to keep track of lead time manually. Doing so would involve recording timestamps for when a feature entered each phase and using these timestamps to calculate how long a feature took end to end. However, this process is manual and prone to errors. A more reliable solution is to use modern tools like DevStats, which can be integrated directly with tools like Jira and GitHub. DevStats can then gather and calculate this information without the uncertainty and inaccuracy that can arise from manual tracking.

‍

Lead time covers the entire implementation process, so if you want to understand and improve that process, lead time is the best metric for that. The key phases to understand for lead time are as follows:

• Requirements gathering: This involves understanding the business problem you are trying to solve, gathering user requirements, and producing requirement documents.
• Prioritization and planning: Once you have established requirements, you will typically go through various processes to refine, plan, and prioritize the work to be done.
• Development and testing: Once work is planned, developers eventually pick it up and begin development. As work is completed, it is tested to confirm that the requirements are satisfied.
• Deployment and release: Once the work is completed and the requirements are satisfied, commits will go through the deployment process, when code is built and ultimately released into production and the requested feature will be available to users.

Lead time is significantly influenced by factors external to the development team. These factors include prioritization decisions made by the product owner and stakeholders, the availability of business resources, and external dependencies. This reliance on external factors highlights a limitation of using lead time as a metric for assessing the delivery performance of your development team. However, lead time remains a valuable metric because it provides a realistic measure of how long it takes to deliver features to users from start to finish. If you're looking to track the performance of the development process more accurately, then *cycle time* might be a more suitable metric.

‍

Cycle Time

Cycle time differs from lead time in that it covers specifically the time the team spends actively working on a task. It can be helpful to think of cycle time as a subset of lead time as it gives you a more focused, granular look at the active development slice of the overall delivery.

Like lead time, cycle time can be tracked in several ways. If you want to track it manually, you would again need to timestamp when work enters each phase. Using that information, you can determine how long each phase takes and the overall cycle time for a piece of work. However, as with lead time, this is highly manual and can lead to mistakes and inaccuracies. A more reliable alternative is to use automated tracking tools like DevStats, which can pull this information directly from relevant tools like Jira and GitHub.

‍

Cycle time focuses on a subset of the overall process but can give you a more in-depth understanding of the key phases involved:

• Development: Typically, the largest time allocation will be for the actual development and coding. This is the phase where the developers actually build the features.
• Code review: Once the code has been created, it needs to be reviewed by other developers to ensure it complies with team standards and to help identify potential issues. If issues are found, the work may be sent back into development.
• Testing: If the work passes code review, testing is conducted to validate that the requirements are satisfied. If requirements are not adequately met, work may be sent back into development for correction.‍
• Deployment: If the requirements are satisfied, the work will go through the deployment process, at which point the cycle is considered complete.

Where lead time is heavily influenced by factors external to the dev team, cycle time is influenced more from within. Development practices have a heavy impact on cycle time, which is part of what makes it such a valuable metric as it allows you to measure the effectiveness of tweaks and changes to these practices and circumstances. This can include things like the size of the dev team, the breadth and depth of skill sets in the team, the application of development methodologies, the effectiveness of the code review process, and the use of automation in testing and deployment processes.

‍

Lead Time for Changes vs. Cycle Time

Despite their similarities, lead time and cycle time have some key differences, and each is suited to specific uses. The main distinction between the two is that lead time covers the end-to-end lifecycle of a requirement or feature, while cycle time only covers the developer time of a piece of work, which might be a whole feature but could be as small as a single-line code change. A task could sit in the backlog for weeks before being worked on by developers, affecting lead time but not cycle time. Aside from this distinction, there are a few other key points that separate these metrics:

‍

‍

Understanding Cycle Time Reports

Whether you track your metrics manually or through an automated process like DevStats, gathered metrics are only useful if you can use them in a meaningful way. Typically, you'll access this data through reports that track your metrics over a given time frame.

‍

Consider this example cycle time report from DevStats:

Here, you have all the key information you need to understand the state of things:

• Configurable time period (days, weeks, months, etc.)
• Breakdown by stages (coding, pickup, review, deploy)
• The ability to filter the data by branches, team members, and issue type

Crucially, this kind of report provides insights into how long each part of your software development process is taking and where there might be bottlenecks that you can optimize.

‍

Optimizing Software Development Using Cycle Time

Access to high-quality cycle time data helps you understand shortcomings in your processes. If you identify in your cycle time report that a particular phase is taking a long time—more than you would expect—it could be a sign that you need to optimize your software delivery process. Here are some common ways to do that.

‍

Streamline Code Reviews

If code reviews are taking a disproportionate amount of your cycle time, there are a few ways you can optimize them. Your first step should be to automate the straightforward stuff. Rather than having human reviewers be on the lookout for code style issues and unused code imports, you should use tools like static analysis and linting to automatically identify these kinds of issues. This leaves your human reviewers free to focus on the actual implementation details of what they are reviewing.

‍

Another great way to optimize code reviews is to make PRs smaller. Ideally, your PRs should be as small as reasonably possible as this allows the reviewer to give the whole PR proper consideration, avoiding the phenomenon where large PRs suffer from lower-quality reviews.

‍

Implement Automation in Testing and Deployment

If your testing or deployment phases are taking longer than you would like, it's worth reviewing your workflows to see if there is any opportunity for automation. If you're doing lots of manual testing for releases, automated regression testing may be able to speed things up and increase consistency and repeatability.

‍

Similarly, if your deployments are currently mostly manual, it could be worth investing some time in streamlining and automating this workflow—if not fully, then at least to the point where the deployment of your latest `main` branch can be done with a click.

‍

Improve Collaboration and Communication

It's easy for developers to lose time during implementation if they get stuck on an issue. This can easily cause work to blow past the estimated timelines, which can frustrate stakeholders and negatively impact your cycle time. While there can be many causes for this, these kinds of issues could often have been solved faster with more devs thinking about the problem. Improving collaboration could be as simple as encouraging individuals to post problems in a public Slack channel to see if anyone else has run across it before or engaging in pair programming with another developer to resolve the issue.

‍

Encouraging collaboration and communication between developers on your team can improve the team's overall performance in this way.

‍

Set Clear Targets for Cycle Time Reduction

While it may be true that you cannot meaningfully improve a metric without measuring it, measuring alone is not enough. You must set a clear target and actively work toward improving a metric before you are likely to see any movement. If improving your cycle time is a priority, make sure it is a well-known priority and that the team is on board as it will ultimately be a collaborative effort.

‍

It is also important to set a realistic target. Cycle time is one of the DORA metrics, so there has been a lot of research into what these metrics should look like for high-performing teams. DORA's 2022 State of DevOps report showed that many high-performance teams had cycle times of less than twenty-four hours. Depending on your current cycle time, you may need to approach this mark in incremental steps; however, either way, it is a good target to aim for as it means you would be doing releases daily.

‍

Wrapping Up

Lead time and cycle time are similar but distinct. Each provides insight into parts of your software delivery processes, with lead time giving a better overall picture and cycle time honing in on delivery details. A solid understanding of these metrics is important if you want to get the most out of your software delivery process as they show you how long things are currently taking and give you the means to make process improvements. If you want to improve your software delivery speed, tracking these metrics is a must; doing so will enable you to optimize your cycle time to achieve faster software delivery and, ultimately, a competitive edge.