A QUICK SUMMARY – FOR THE BUSY ONES
The four DORA metrics are used by DevOps teams to visualize and measure their performance. They represent the velocity and stability of deployment. The metrics allow team leaders to take steps towards streamlined processes and increased value of the product.
TABLE OF CONTENTS
DORA metrics give a high-level view of a team's performance, allowing to assess how well the team balances speed and stability and spot areas for improvement.
That allows engineering leaders to continuously streamline processes and increase the speed of delivering customer value, which is crucial for a product to remain competitive.
Let’s break these metrics down and analyze how you can implement them easily.
DORA metrics are four indicators used to calculate DevOps team efficiency. They measure a team’s performance and provide a reference point for improvements. They also help to make data-driven decisions.
The metrics were invented by an organization gathered by Google and called DevOps Research and Assessment (DORA). They surveyed thousands of development teams from various industries to understand what differentiates a high-performing team from the others. Establishing DORA metrics is the result of this research.
DORA metrics were explained for the first time in the DORA organization’s report ﹣ Accelerate: State of DevOps 2018. The report is released on a regular basis ﹣ the newest version was released in 2021.
<span class="colorbox1" fs-test-element="box1"><p>Key takeaway:</p><p>DORA metrics show what level of performance is needed to achieve desired business objectives.</p></span>
The metrics reflect key areas that influence performance and equip engineers with detailed insights.
By measuring the velocity of development and stability of deployment and the product itself, teams are motivated to improve their results during subsequent iterations. And improving them leads to better business outcomes.
DORA uses its metrics to identify Elite, High, Medium, and Low performing teams. They claim that Elite teams are twice as likely to meet or exceed the performance goals of the organization.
DORA metrics make the process of software delivery more transparent and understandable, breaking it into pieces.
DORA metrics help teams to:
<span class="colorbox1" fs-test-element="box1"><p>Note:</p><p>Implementation of DORA metrics and the whole DevOps culture is also one of the indicators of the best dev shops. Pay attention to that aspect while choosing an external software development company to work with.</p></span>
At the highest level, Deployment Frequency and Lead Time for Changes measure velocity, while Change Failure Rate and Time to Restore Service ﹣ stability.
The Deployment Frequency metric refers to the frequency of successful software releases. It measures how often a company successfully deploys code to production for a particular application.
Deployment Frequency depicts the consistency and speed of software delivery. It determines whether a team is meeting goals of continuous delivery.
Smaller and more frequent deployments are the target, but the most effective number of deployments will differ from product to product. Delivering code quickly to production comes from shipping as many times as possible while changing the batch size to be as small as possible.
<span class="colorbox1" fs-test-element="box1"><p><strong>Key takeaway:</strong></p><p>Deploying often allows the team to constantly improve the product, and spot issues easier.</p></span>
Various tools measure Deployment Frequency by calculating how often a team completes a deployment to production and releases code to end-users.
To measure the frequency, calculate the median number of days per week with at least one successful deployment.
Deployment Frequency depicts how well your current process is functioning.
By spotting specific periods when deployment is delayed, you can identify problems in a workflow ﹣ unnecessary steps or issues with tools. You can also recognize problems like staff shortage or the need for longer testing time.
Deployment Frequency also allows for comparing deployment speed over time and mapping your team’s velocity to deliver.
There may be several reasons for low Deployment Frequency, often related to the process and tools:
To increase your team’s ability to deliver, try to:
Lead Time for Changes indicates how long it takes to go from code committed to code successfully running in production. Along with Deployment Frequency, it measures the velocity of software delivery.
Lead Time for Changes allows us to understand what the DevOps team cycle time looks like, and how the team is handling an increased number of requests.
The team should strive for the low Lead Time for Changes ﹣ the lower it is, the more efficient a team is in deploying code. It means that a team is able to respond to feedback faster and correct the course rapidly. Defects are most likely being fixed quickly.
To measure Lead Time for Changes, you need two pieces of data:
Then, use the average time as an indicator of overall performance. Lead Time for Changes is an approximation.
Lead Time for Changes is an indicator of how quickly a team responds to needs and fixes. It represents the efficiency of the process, code complexity, and team’s capacity.
The metric helps to understand how long it takes to get changes to production. When Lead Time for Changes is too high, it shows inefficiencies and bottlenecks in the process. A low one shows that a team reacts to feedback and changes quickly
<span class="colorbox1" fs-test-element="box1"><p><strong>Key takeaway:</strong></p><p>The team’s goal should be to reduce Lead Time for Changes and react to issues in a timely manner.</p></span>
This metric is also essential while working with clients, who prefer to work with a team that responds to urgent bug fixes within hours. Making changes quickly keeps clients satisfied.
High Lead Time for changes is most often caused by inefficient processes and introducing too big changes to production. Other reasons are:
To reduce Lead Time for Changes, try to:
Mean Time to Recovery, Time to Recover, or Time to Restore Service. This metric goes by many names. But, what’s most important, it measures how long it generally takes to restore service when a service incident or a defect that impacts users occurs.
Simply speaking, it’s the time it takes for a service to bounce back from a failure.
<span class="colorbox1" fs-test-element="box1"><p><strong>Key takeaway:</strong></p><p>Failures can’t be avoided, so what makes a difference is how quickly a system can be restored or recovered.</p></span>
Time to Restore is calculated by tracking the average time between a bug report and the moment the fix is deployed.
The formula for that could look like this:
average(incident resolved timestamp ﹣ incident created timestamp).
Time to Restore Service indicates a team’s response time and development process efficiency.
When Time to Restore Service is too high, it may be revealing an inefficient process, lack of people, or an inadequate team structure. When it’s low, it shows that a team responds and solves problems quickly. Low Time to Restore Service ensures availability and correct functioning of the software.
The team’s goal should be to reduce Time to Recover. Then, when there’s an incident, a team can fix it in a timely manner, so the availability of software isn't compromised.
There are various aspects that can increase Time to Restore Service:
To reduce Time to Restore Service, do the following:
Change Failure Rate measures the percentage of deployments causing failure in production ﹣ the code that then resulted in incidents, rollbacks, or other failures.
<span class="colorbox1" fs-test-element="box1"><p><strong>Key takeaway:</strong></p><p>Change Failure Rate is a measure of stability and quality of software delivery.</p></span>
Change in Failure Rate is inspired by Lean principles. Over time the metric provides insights on how much time is spent on fixing bugs versus delivering new code.
Change in Failure Rate is calculated by counting the number of deployment failures and dividing it by the total number of deployments.
Change Failure Rate shows how well a team guarantees the security of changes made into code and how it manages deployments. It’s an indicator of a team's capabilities and process efficiency.
<span class="colorbox1" fs-test-element="box1"><p><strong>Key takeaway:</strong></p><p>The metric also shows how much developer’s time is devoted to tasks that don’t contribute to business value.</p></span>
A high Change Failure Rate indicates problems in the development process or lack of testing before deployment.
A low Change Failure Rate shows that a team identifies infrastructure errors and bugs before the code is deployed. It’s a sign of a sound deployment process and delivering high-quality software.
The DevOps team’s goal should be to reduce Change Failure Rate to ensure software’s availability and correct functioning.
Behind the high Change Failure Rate are often inefficiencies in testing. It is also caused by:
If your Change Failure Rate is high, make sure to:
<span class="colorbox1" fs-test-element="box1"><p>To many permissions? Discover how the CASL library can simplify your web application's permission management with its intuitive and flexible approach.</p></span>
<span class="colorbox1" fs-test-element="box1"><p><strong>Key takeaway:</strong></p><p>Improving the metrics shouldn’t be the goal by itself ﹣ the ultimate goal teams need to focus on is to improve the way they deliver a product to increase its value faster and in a stable way.</p></span>
There are various tools that help to implement DORA metrics:
To help teams generate these metrics, DORA created the Four Keys open source project. It automatically sets up a data ingestion pipeline, getting data from teams’ Github or Gitlab repos through Google Cloud and Google Data Studio.
The Four Keys project aggregates data and compiles it into a dashboard using four key metrics. You can track the progress over time without the need of using extra tools or creating solutions on your own.
For some companies, DORA metrics will become a starting point, which then needs to be customized to fit their project.
During the implementation, pay attention to:
One of the biggest problems is also the assessment speed versus stability. To avoid mistakes, you always need to put singular metrics in context. A high Deployment Frequency doesn't say anything about the quality of a product. To assess the quality, a Change Failure Rate will be a good indicator.
It’s not only about becoming an elite performer. It’s about delivering better business value faster.
By measuring and tracking DORA metrics and trends, teams can make better, more informed decisions about what can be improved, and understand how to do that. When DORA metrics improve, a team can be sure that they’re making good choices and delivering more value to customers and users of a product.
As an engineering leader, you need to empower your team with tools to achieve that.
DORA metrics can help you boost your DevOps performance by increasing velocity and stability, but your team can build even better products after implementing the BizDevOps approach. BizDevOps smashes the walls not only between developers and operations but also the business. It allows teams to make more informed decisions, speeds up the feedback loop, and results in building products that meet the business needs more efficiently.
<span class="colorbox1" fs-test-element="box1"><p><strong>Need help?</strong></p><p>You don’t have to figure it all out on your own. Let’s chat about DORA metrics implementation and accelerate your growth together.</p></span>
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Software development enthusiast with 6 years of professional experience in the tech industry.
Top reads this month
Get smarter in engineering and leadership in less than 60 seconds.
Join 300+ founders and engineering leaders, and get a weekly newsletter that takes our CEO 5-6 hours to prepare.
No previous chapters
No next chapters