DevOps Metrics #3: Change Lead Time

December 7, 2017


When looking to start working with DevOps, you’ll sometimes find that you don’t know whether or not your efforts has been effective. Since you put down all that time and energy towards something, you need to know if you’ve succeeded or just wasted your time, right? This is where metrics come in. DevOps metrics are measurable numbers that determine how successful your DevOps efforts are. In this third blog post in the DevOps Metrics series, we’ll take a closer look at Change Lead Time.

Puppet specifies change lead time as one of the main differentiators between high and low performers. With high performing companies having change lead times as short as an hour, it’s easy to see why it’s worth taking a look at.

Change Lead Time

Change Lead Time, also known as just lead time or Mean Time To Change, is defined as follows:

The time it takes for a bug fix, new feature or any other change to go from idea to deployment to production. 

The metric itself speaks of how efficient your development process is. This metric depends on your existing code complexity, technical debt, architecture as well as team and individual capabilities. If the change lead time is very long, it might be a sign that something in the development chain isn’t as efficient as it could be. Another useful way to improve on this is to find bottlenecks and work to remove them.

On the other hand, a short change lead time enables you to quickly react to feedback or market incidents. Your CIO and CTO most certainly appreciates that. Paired with better feedback loops and a higher release frequency, this creates better opportunities to deliver value to your end users.

How to measure

Unfortunately, not many measure this metric yet. Change lead time can be separated into two different metrics:

  • The time from idea to deployment to production
  • The time from when actual coding starts to deployment to production

The difference between these two is that the first version includes everything leading up to development. In addition to meetings and discussions, this can be design reviews, scheduling, planning and more. If some obstacle causes coding to be delayed, this takes that into account as well.

Both are measured by simply start counting from the moment somebody comes up with the idea for a change (or when the actual development starts, if you go by the second version), and stop counting when the change has been successfully deployed to production. The idea is that with time, this metric should become shorter and shorter.


The change lead time could be one of the most valuable metrics to measure in your DevOps initiative. It’s one of the most holistic measures out there and takes variables from many different areas into consideration.

While other metrics such as Mean Time To Recovery (MTTR) showcases the ability to fix acute problems, change lead time shows you how well you can meet changing demands. Overall, it’s a great way to keep track of how your DevOps transformation is going.


Have you started measuring your change lead times? What other metrics do you measure? Leave a comment in the section below!