What Are the DORA Metrics?

The success of engineering efforts can be complex and multifaceted. Often, engineers face challenges—such as unanticipated rework, blocking issues, and inefficiencies—that can hinder their productivity. To address these challenges, you need to be able to measure their performance using appropriate metrics.

‍

This is where the DORA metrics come in. They offer a framework for evaluating the performance and efficiency of engineering teams in delivering software. Understanding and using these metrics properly can help engineering teams function optimally, contributing to your organization's success.

‍

In this article, you'll learn what the DORA metrics, how they can help you improve your software development processes, and how to easily calculate and track them using DevStats.

‍

What Are the DORA Metrics?

DORA, short for DevOps Research and Assessment, is a framework developed by Google to assess the performance of engineering teams. The DORA metrics evaluate key aspects of software delivery to identify issues and discover opportunities for improvement.

‍

The first two DORA metrics (deployment frequency and lead time for changes) measure the throughput of software changes, while the last two (change failure rate and failed deployment recovery time) measure stability.

‍

The DORA metrics focus on throughput and stability instead of directly measuring productivity. Considering these two focus areas together rather than separately makes the DORA metrics more reliable and less open to misinterpretation. An ideal team can implement changes quickly while maintaining system stability.

‍

Let's explore the four DORA metrics in more detail.

‍

Deployment Frequency

Deployment frequency measures how often you release a new version or update for your project. It indicates how quickly and efficiently new features, updates, and fixes are delivered to users. High-performing teams typically release a large number of versions with small change packages. Smaller change packages reduce risk and make it easier to track and resolve issues.

‍

Deployment frequency varies widely among companies. Some companies accumulate a significant codebase before deployment, sometimes up to six months. Others deploy code every day. Based on the 2023 DORA benchmarks, a company's deployment frequency can fall into four performance levels:

‍

• Elite: deploy multiple per day
• High performing: deploy between once a day to once a week
• Medium performing:  deploy between once a week to once a month
• Low performing: deploy less than once a month

‍

Regardless of where they fall on the benchmark, companies that know their baseline can intentionally create processes to improve their deployment frequency, enhancing the way they deliver software on a daily basis.

‍

Lead Time for Changes

Lead time for changes shows how quickly your DevOps process can activate new features by measuring the time between when a developer commits code and when it's deployed to production. It's closely related to development frequency: shorter lead times are frequently linked with higher deployment frequency.

Lead time for changes enables quicker feedback loops and timely corrections. Unlike other metrics, it's consistent regardless of contextual complexity.

‍

The 2023 DORA benchmarks for change lead time are as follows:

‍

• Elite: less than a day for a commit to get deployed to production
• High performing: between one day and one week
• Medium performing: between one week and one month
• Low performing: between one week and one month

‍

Lead time for change is measured with issue trackers, CI/CD pipelines, Git hooks, and code repositories, which, in turn, use patterns, tags, and branches for analysis. Lengthy lead time may result from unplanned changes, unclear requirements, manual testing, complex approval processes, and excessive red tape.

‍

To reduce lead time, prioritize small, self-contained changes, include automated tests into CI/CD pipelines, and consider code deployment models such as trunk-based or feature-toggle-based approaches. These strategies can improve deployment frequency and efficiency.

‍

Note that simply increasing the frequency of deployments does not always result in improved performance. Improving lead time for change must take factors such as code review efficiency and testing effectiveness into account.

Change Failure Rate 

Change failure rate (CFR) evaluates the quality of your code deployments by measuring the percentage of deployments requiring rollbacks due to bugs or incomplete features. Low CFR indicates high process maturity that minimizes end-user disruptions.

To calculate CFR, divide the number of faulty deployments by the total number of deployments in your selected time frame and then multiply that figure by one hundred to get the percentage. Note that if an issue that's not related to the deployed changes occurs, it shouldn't affect CFR calculations.

The 2023 benchmarks for CFR performance are as follows:

• Elite: 5 percent
• High performing: 10 percent
• Medium performing: 15 percent
• Low performing: 64 percent

High CFR may stem from manual deployment processes or non reproducible infrastructure changes. Versioning infrastructure as code helps replicate environments and detect bugs early. Automated tests also help reduce complex and error-prone manual testing.

Another way to mitigate high CFR is to opt for smaller, self-contained code versions. It reduces the risk associated with each deployment, and issues can be identified and resolved more quickly. This leads to a higher overall success rate in your deployments. It also helps to detect and address bugs in early development stages using code reviews and automation wherever possible.

Failed Deployment Recovery Time

Failures are inevitable in complex software environments, so the question is, How quickly can you recover?

‍

Failed deployment recovery time measures how long it takes to restore service to a stable state after an incident caused by a change in production. A short failed deployment recovery time shows that your team can manage production incidents effectively and recover from them quickly to maintain reliable service.

To calculate this metric, identify the period you want to assess, track the time between when a problem is detected and the solution is deployed, and calculate the average of these times. The 2023 DORA benchmark identified the following four performance levels for failed deployment recovery time:

• Elite: Your system can be stabilized in less than an hour.
• High performing: It takes more than an hour but less than twenty-four hours to stabilize your system.
• Medium performing: It takes more than a day but less than a week to stabilize your system.
• Low performing: It takes more than a week to stabilize your system.

Improving failed deployment recovery time involves using automated tests integrated into your CI/CD pipeline, providing clear documentation for your incident management process, and implementing feature flags. Feature flags allow you to take a faulty feature offline quickly, minimizing disruption to users and providing more time to fix the problem. Automating steps in your incident management process to reduce manual intervention and implementing specific error warnings and monitoring tools can also help.

How to Implement the DORA Metrics

Now that you know what the DORA metrics are, let's see how you can calculate them using DevStats.

‍

Start by signing up for free and add your team. From your admin account, you manage your teams and team members as needed.

Next, you'll connect your team's code repository from platforms like GitHub, GitLab, or BitBucket. These connections provide the behavioral data needed to track team health and performance.

Once your team and data are all set, you can use DevStats to see where your team excels and where there's room for improvement. The platform uses a range of industry-proven methodologies, including the DORA metrics, to give specific data for tracking team performance and guiding improvement.

‍

DevStats helps you get insights into your team's deployment frequency, totals, and change failure rates. By using the DORA metrics, you can understand how quickly your team finishes development cycles and identify areas for continuous improvement in your deployment processes.

‍

Conclusion

The DORA metrics help you assess and enhance the performance of software teams. The four metrics—deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time—offer insight into both the throughput and stability of your development process.

‍

The DORA metrics help your team improve over time. Regularly tracking these metrics can help you identify areas that need to improve, set goals, implement changes, and measure the effectiveness of those changes.