DevOps By The Numbers – 5 Metrics To Watch

| July 21, 2016 | 7 Comments

Tim Buntel recently sat down with Alan Shimel of and explored DevOps by the Numbers. This discussion looked at how to approach the measurements and metrics of a Continuous Delivery transformation. Tim spoke on tough questions like “are we getting better at delivering high-quality software faster and at scale?” and “has all this effort been worth it?!” After listening to the entire discussion we compiled the top 5 DevOps metrics to watch:


Time to Delivery

“Looking at your time to delivery across all the phases in your development process is a great tool to help you identify which of those stages you should tackle first.” – Tim Buntel, VP of Products

This provides insight into the specific processes slowing the pipeline down and what actions should be taken to decrease time to delivery. It’s important to remember, however, to focus your automating efforts on a select few areas of inefficiency at a time, as opposed to trying to do everything at once.


Deployment Frequency

Examining how often a company deploys software tells a lot about what is causing bottlenecks that slow down the process. A benefit to regular deployments is that it provides more opportunity to improve your software.

If it takes you a very long time and you’re deploying less frequently then you’re going to be less able to respond. That suggests that you need to rethink the batch sizes that you’re delivering.” – Tim Buntel, VP of Products

In addition, processes dependent on manual labor as opposed to automated ones will only lengthen time between deployments. Automation will not only increase frequency but will also provide you with enough time to respond to any errors.


Change Volume

“Releasing frequently is only important if what you’re releasing is valuable. Thinking about what the volume of changes in the releases is a really important metric to bring into the conversation.” – Tim Buntel, VP of Products

However, the value of change will differ depending on each company’s specific software process. Agile companies often turn to user stories or points as the unit to measure change volume. It is essential for each release to come with its own meaningfulness in order to be a change worth making. Be sure to steer clear of lines of code as a unit of measurement as they tend to lack the complexity necessary for change.


Success Rate

Frequency and meaning behind your releases may be all for neigh unless it actually works. Be sure to keep an eye on the success rate, which, despite its name, is a unit of measurement focused on the number of times deployment to production resulted in failure. Failure is not to be feared, but rather embraced as an opportunity to learn.

“It’s important to get your releases and changes into production, but if they result in an outage it’s important for you to know that it happened because that’s going to tell you whether there’s quality in both your code and your process.” – Tim Buntel, VP of Products

These failures are usually a warning of configuration drift, which is often experienced by organizations undergoing a DevOps transformation.


MTTR (Mean Time to Recovery)

The debate between measuring Mean Time to Recovery (MTTR) and Mean Time Between Failures (MRBF) is very prevalent in DevOps. Our recommendation is as followed:

“Focus on time to recovery because faster delivery—being more agile—opens up more opportunity to failure but they’re not inherently bad. What’s important is can you react to them…can you take the evidence that comes out of that event and prevent it in the future.” – Tim Buntel, VP of Products

Failures in continuous automation are inevitable, but true failure lies in not responding to them fast enough. After all, knowing how well your team can handle unfamiliar situations is more useful than how long they’ve gone without them.


Above & Beyond 

These 5 metrics are the primary measurements used to optimize DevOps processes. However, depending on your industry there may be others that can come in handy. Adoption, or whether people are actually utilizing these new changes, can also be beneficial. This can be measured by a variety of factors such as application traffic, calls to Application Program Interfaces (API’s), new user sign-ups, and performance. Consumer happiness with the product is another useful measurement that uses social media to receive feedback from users. Business impact such as trial conversions, or what the market is saying about the company, helps prove that DevOps is a useful tool and can improve the continuous delivery process. Finally, and not as common is cultural impact, which focuses more on the internal such as staff turnover or morale gaged from surveys.


Listen to the entire discussion!

Continue reading about Continuous Delivery in the enterprise with “Simple Steps to Improve Applications Deployments to Microsoft Environments.”

Divesh Rupani

About the Author ()

  • Tim Coote

    Are you sure about deployment frequency? sounds like a stick to beat QA with (assuming Continuous Delivery, rather than Continuous Deployment).

    Has anyone established a reasonable measure of ‘design thrash’: how close were we to the optimal route between A and B, could we have learned the necessary questions and answers sooner/more cheaply?

    From a biz case point of view, there’s also a question of valuing the trade-off between ‘design’ and ‘evolve’.

    • Tim Buntel

      Hi Tim,

      Absolutely sure! The quicker you can deliver features to customers, the quicker you can act on their response to the change. It yields a continuously improving customer experience and lets you be more innovative. The newly released 2016 State of DevOps report found that “High-performing IT organizations deploy 200 times more frequently than low performers.”

      Far from being a stick to QA, quality is built into the entire system in a healthy DevOps model. QA no longer all about “finding bugs;” it’s about improving both the product and the process.

      I’m not sure I follow you entirely about design vs evolve. “Evolve” should always be the goal: evolving the product incrementally to continually deliver value to the user, and evolving the process to optimize our ability to do so.


      • Tim Coote

        Hi Tim
        The challenge to frequency comes from Humble and Farley’s book, and my experience with deploying against external systems: the overall environment has to work as a whole and it can take some time to get other stakeholders’ systems ready to accept a new release. Also, there are likely to continue to be tests that continue to be non-automatable, so you need a QA gate (again, as per the book).

        By design vs evolve, I was comparing agile development approaches with other search techniques (such as natural evolution). Only using short-range searches from the current position can lead to falling into local minima. How big a risk is falling into such a local minimum?

        To posit an example that’s close to top of my mind at the moment, if the system is based on a security model where access control is based on who a process is acting on behalf of, it’s hard to shift that wholesale to the alternative Capability model, as the shift involves rethinking how all user interactions work to ensure that the security intent and impact is clear at the time of interaction (eg if I hand over the keys to my car, I’m implying that the person that I’m handing them to can drive the car, or just look in the boot, or share them with someone else at the time that I hand them over).

        I don’t immediately see how to make the shift in small increments.


        • Rob Vanstone

          Hi Tim

          As with evolution I think there’s room for step changes in an incremental approach. In our case feedback is critical to this because insightful feedback can lead to (non-random) pivots that we can experiment with (incrementally if needs be).

          Without being too dogmatic about the analogy with evolution theory we at least have the power to make some educated guesses with the direction of our development. With the peace of mind that comes from the ability to release often and safely we have the opportunity to get this feedback equally as often.

          WIth some analysis we could probably design in some safety features to mitigate the risks you speak of, so to take your point, give someone the keys but disable the ability to drive if required. Perhaps that ability is created prior to me handing over keys in an earlier release.

          The (slightly laboured) point here is that rather than blindly incrementing our software we can apply our intellect on creating new features without worrying too much about how to get them in front of our customers if we have solved the frequency problem…


    Should we add “Service Availability” as a Key metric?