Lead Time, Cycle Time & Change Lead Time

Lead Time, Cycle Time and Change Lead Time all measure very different things in the Software Development Lifecycle, and are used for very different purposes. As an engineering productivity tool, at Haystack we tend to focus on allowing people to improve Change Lead Time and this is the metric we now serve to all users in the Haystack dashboard by default.

In this blog post we’d like to explain the differences between these three metrics and share the evidence on why Change Lead Time is a critical DevOps metric to track when building an elite engineering team.

Software Development Lifecycle

The (Agile) Software Development Lifecycle is typically broken down into a few different phases. Work to be done will typically start in a backlog to be groomed and then be assigned to a developer to work on. After this, a developer will then start development. Once this is done, automated tests will kick-off and the team will peer-review the code. Once the software is cleared for release, it will be shipped out to the world.

These processes can be measured using our three metrics, which are broadly described below:

Lead Time

Lead Time will typically cover the entire time taken for a feature to be filed and to then go into production, this includes the time the feature spends in the backlog.

In teams with non-groomed backlogs, tickets can sometimes spend a lot of time in the backlog before they’re worked on, whilst other tickets are processed very quickly. This means that Lead Time is generally an unsuitable metric in truly agile teams, but might be more relevant in teams working on large projects, in a waterfall structure where there are fewer customer feedback cycles.

In almost all online businesses, strong prioritisation of customer needs is more important than measuring an overall Lead Time metric.

Lead Time itself is not a metric that the engineering team will often control. Product Managers or the business will determine what work is prioritised, making this a poor metric for an engineering team to use.

Cycle Time

Cycle Time measures the entire lifecycle of work on a feature - from starting development work to code being deployed. This gives a holistic view of the development process.

The quicker this process is, the quicker you're able to get new features in front of real-world users for fast feedback. The end result is hopefully a product that better suits customer needs.

This metric is imperfect though.

Whilst the processes at the end (testing, reviewing, deploying) can benefit vastly through process improvement and automation, the actual software development process in the middle is far more unpredictable and harder to measure. It’s more important to ensure work is appropriately broken down and not attempt to micromanage engineers when developing.

Cycle Time can be a useful metric for Delivery Managers and Product Managers to watch to ensure iterations are quick enough to adjust course based on user feedback but don’t really help the engineering team improve their own processes and systems.

Change Lead Time

Change Lead Time is one of the Four Key DevOps Metrics defined in the Accelerate book and in Google’s State of DevOps reports.

It measures the most predictable and easy to optimise part of the development lifecycle - first commit to deployment. Whilst this is also the most accurate part of the development lifecycle to measure, tools like Haystack will also provide you options to gain additional accuracy from these measures, by setting global filters and being able to exclude draft Pull Requests from these calculations.

This measure provides you an insight into how you can best improve the most repeatable part of the software development pipeline to allow your team to become an elite performer. By being able to take features as quickly as possible from developers to real-world users you can deliver value quicker, get feedback that shapes your product roadmap quicker all whilst the new automation will allow you to ship software more reliably than ever before.

Indeed, Google’s State of DevOps Reports (in research led by Dr Nicole Forsgren) has shown that companies that do well under these DevOps metrics have a 50% higher market cap growth over 3 years.

Change Lead Time is also fully within the control of the engineering team, meaning that it is the right metric for the engineering team to set their own goals around and use to measure their own performance.

Conclusion

In this blog post, we’ve covered the three main time metrics for monitoring a Software Development Lifecycle. All these metrics have different purposes and can help with different things.

For DevOps projects, where tools like Haystack are most used, Change Lead Time makes sense as the key measure.

Change Lead Time is a metric that can be fully owned by the engineering team, meaning it can be used for setting goals and targets to improve the engineering process. Moreover, research has shown that this metric is highly correlated to superior business metrics.

Nevertheless, if you’d like to get other metrics - reach out to the Haystack team so we can see how to best support your needs. Whilst we like to focus on the metrics proven to deliver the highest chances of success, custom reports can be generated in the dashboard using our Query Builder.