Articles
Tutorials
Interactive Guides
DORA metrics: How to measure Open DevOps success
DevOps Research and Assessment (DORA) provides a standard set of DevOps metrics used for evaluating process performance and maturity. These metrics provide information about how quickly DevOps can respond to changes, the average time to deploy code, the frequency of iterations, and insight into failures.
This guide overviews the four DORA metrics, their importance, and how teams can use Open DevOps to measure performance.
What is DORA?
DORA originated as a team at Google Cloud specifically focused on assessing DevOps performance using a standard set of metrics. Their goal is to improve performance and collaboration while driving velocity. These metrics serve as a continuous improvement tool for DevOps teams everywhere by helping set goals based on current performance and then measuring progress against those goals.
DevOps is critical in keeping business software and processes running smoothly so users can focus on their work. DORA metrics are crucial in helping DevOps teams:
- Provide realistic response estimates
- Improve work planning
- Identify areas for improvement
-
Build consensus for technical and resource investments
What are DORA metrics?
DORA metrics for DevOps teams focus on four critical measures:
- Frequency of deployments
- The amount of time between acceptance and deployment
- How frequently deployments fail
- How long it takes to restore service—or recover from a failure
The following discusses why these metrics are DevOps best practices, their measurement, and what teams can do to improve their performance.
Deployment frequency
DevOps teams generally deliver software in smaller, more frequent deployments to reduce the number of changes and risks in each cycle. More frequent deployments allow teams to collect feedback sooner, which leads to faster iterations.
Deployment frequency is the average number of daily finished code deployments to any given environment. This is an indicator of DevOps’ overall efficiency, as it measures the speed of the development team and their capabilities and level of automation.
Reducing the amount of work or the size of each deployment can help increase deployment frequency.
Lead time for changes
Lead time for changes measures the average speed at which the DevOps team delivers code, from commitment to deployment. It indicates the team’s capacity, the complexity of the code, and DevOps’ overall ability to respond to changes in the environment.
This metric helps businesses quantify code delivery speed to the customer or business. For example, some highly skilled teams may have an average lead time of 2-4 hours for changes, whereas for others, it may be a week.
Reducing the amount of work in the deployment, improving code reviews, and increasing automation can help reduce lead time for changes.
See solution
Tools for an elite DevOps team
related material
The importance of team structure in DevOps
Change failure rate
Change failure rate is the percentage of deployments that cause a failure in production. Deployment frequency and lead time for changes are suitable measures of DevOps automation and capabilities, but only if those deployments succeed. The change failure rate is a countermeasure to frequency and speed.
This metric can be challenging to measure because many deployments, especially critical response deployments, can generate bugs in production. Understanding the severity and frequency of those issues helps DevOps teams measure stability against speed.
Reducing the amount of work in progress in the deployment, as well as increasing automation, can help reduce the change failure rate.
Time to restore service
Response time is critical when something goes wrong in the production environment. Whether it is an external security threat or a bug that has brought standard processes to a standstill, DevOps teams must be able to respond rapidly with:
- Bug fixes
- New code
Updates
The time to restore services, or mean time to recovery, is the average time between encountering the issue and resolving it in the production environment.
A response plan helps teams understand how to address issues before they arise, ultimately decreasing the time to restore service.
Why DORA metrics matter
To understand DevOps, recognize that the development and operations teams were historically separate with little collaboration or insight into each other’s work. DevOps, which has become a widely adopted alternative, merged the two teams into one.
One of the benefits of DevOps includes collaboration among multidisciplinary teams, which improves the quality of solutions with faster delivery.
DORA uses these metrics to identify and rank team performance. For each metric, teams get a level (Low, Medium, High, and Elite). For example, to receive an Elite ranking for change rate failure, the team must consistently perform at 0-15%, and to achieve Elite in time to restore, the team must be able to resolve issues within one hour. The team’s combined ranking across all metrics determines the overall ranking.
Knowing how your team compares against the industry is an excellent place to identify where to focus improvements. DORA metrics provide the baseline for setting goals and measuring progress.
How to implement DORA metrics
When implementing DORA metrics, analyze all four measures together. For example, a consistently high deployment frequency doesn’t tell the whole story if the change rate failure is also consistently high.
It may be necessary to focus more on automation and code reviews. Likewise, a low change rate failure can look great, but if the lead time for changes is too long, you may need to break the work into smaller chunks.
To start, create a DevOps pipeline that parses data sources in changes, incidents, and deployments:
- Extract data from its inception.
- Parse it into tables of changes, deployments, and incidents.
- Calculate performance based on the metrics.
Open DevOps provides teams with the tools to develop, deploy, and operate software. Jira Software powers Open DevOps, the #1 tool among agile teams. Thanks to integrations with leading vendors and Marketplace apps, teams can build the DevOps toolchain they want.
DORA metrics and value stream management
Value stream management is the practice of delivering frequent, high-quality releases to customers. A successful measure of value stream management is that the customer realizes the value of the changes.
DORA metrics play an important role in value stream management because they provide the baseline measures for capturing:
- Deployment frequency
- Lead time for changes
- Failure rate
-
Time to restore service
When combined with customer feedback, DORA metrics inform DevOps teams where to focus improvement efforts and how to position their services against competitors.
Use DORA metrics for Open DevOps success
As teams start DevOps, implementing DORA metrics is essential to their success. Open DevOps helps teams track DORA metrics to measure DevOps health.
With Open DevOps native integrations, teams can build the toolchain for end-to-end software development and implement DORA metrics to measure success. Top DevOps tools include:
- Jira Software is the number one choice of agile software development teams for scheduling and tracking work.
- Bitbucket allows development teams to store and track code and control changes.
- Confluence provides knowledge management and collaboration tools for teams to capture, analyze, and share information.
-
Jira Service Management helps DevOps teams track and manage incidents and capture critical DORA metrics.
Optimize your software delivery process and set your team up for success with Open DevOps, which has everything you need to develop and operate immediately.
DORA metrics: Frequently asked questions
What are the common challenges of DORA metrics?
When implementing DORA metrics, set the tone with team members early. Collecting data and publishing performance information can seem threatening to some people. To mitigate this, invite everyone to participate in the following:
- Data collection
- Idea generation
-
Goal setting
Ask what is achievable and what is a stretch goal.
Work collaboratively to analyze and discuss results. While anyone may have an opinion about a specific area, such as automation, engaging the members responsible for that area is critical to getting buy-in and cooperation.
How can your company continuously improve using DORA metrics in Open DevOps?
DORA metrics help teams balance speed and quality. You may aim to earn a DORA Elite DevOps team status but start where you are and work toward that goal over time.
Keeping a team engaged in continuous improvement can include setting ambitious long-term goals if people understand that short-term, incremental improvement is the path to get there.
Break goals into specific, achievable metrics for defined areas of DevOps—for example, decreasing time to recovery by 25% with a 10% or less change failure rate. This provides a meaningful goal that builds on the team’s current capabilities.
How do DORA metrics align with the principles of Open DevOps?
DevOps performance can be challenging to measure, especially for complex projects. DORA provides reliable metrics to help teams put their performance into context.
DevOps aims to bring development and operations together to increase performance and capabilities. DORA metrics support these values with end-to-end visibility. Teams that can track continuous improvement remain motivated and focused.
Share this article
Next Topic
Recommended reading
Bookmark these resources to learn about types of DevOps teams, or for ongoing updates about DevOps at Atlassian.
DevOps community
DevOps learning path
