DORA metrics give engineering leaders insight into the health and performance of the software delivery lifecycle (SDLC) and are an essential starting point for improving software engineering processes. On their own, they help leaders see the tradeoffs between speed and quality.
But the magic happens when viewed in context with other metrics. For example, pairing DORA with data about Cycle Time, Revert Rate, and other indicators of team health can help leaders uplevel their engineering organisation from average to peak performance.
How leaders use DORA to understand engineering performance
The four DORA metrics are Deployment Frequency (DF), Mean Lead Time for Changes (MLTC), Mean Time to Recovery (MTTR), and Change Failure Rate (CFR).
These metrics allow teams to determine the speed and stability of their engineering organisation. For leaders who want to measure their engineering performance against the rest of the industry, Google created the Accelerate State of DevOps Report. This annual report includes a benchmark assessment of DevOps performance based on DORA and operational and organisational performance.
According to Google, this is what performance looked like in 2022:
● Deployment Frequency: High-performing teams have a DF of at least once a week, with the best teams deploying multiple times daily.
● Mean Lead Time for Changes: The best teams have an MLTC between one day and one week.
● Mean Time to Recovery: Average teams have an MTTR of under one week, and high-performing teams can usually recover in less than one day.
● Change Failure Rate: Most DevOps teams have a CFR between 0% and 15%.
Viewing DORA metrics in context
DORA metrics measure outcomes—they help leaders determine what needs further investigation and what needs to improve. When this information is seen in context with other SDLC metrics, it’s easier to pinpoint specific areas for improvement so that engineering teams can achieve peak performance.
For example, viewing metrics in tandem may reveal that when a team has many unreviewed PRs, their Change Failure Rate is also higher than usual. With that information, they have a starting point for improving CFR and can put in place processes for preventing unreviewed PRs from making it to production.
Engineering leaders can coach teams to improve these metrics by reinforcing good code hygiene and shoring up CI/CD best practices. Conversely, if these metrics indicate that things are going well, they can determine what a team or individual is doing and double down on those practices.
Metrics to pair with DORA
Measuring DORA in the context of other engineering metrics helps leaders get a complete picture of team health and performance. Here are some examples of what metrics to pair.
- Deployment Frequency and PR Size: Leaders can use PR Size as a starting point for investigating a low DF. If a correlation between large PRs and less-frequent deployments is found, they can coach team members to break work into smaller PRs to see if DF improves.
- Mean Time to Recovery and Revert Rate or Defect Rate: A long MTTR could indicate a high Revert Rate, which disrupts production and lengthens the time it takes to recover from an unplanned outage or defect. If leaders notice a correlation, they can drill down into each revert and see whether the issue is a defect or an undesirable change.
To prevent defects in the future, leaders may consider implementing automated testing and/or code review. Sometimes, the solution lies further upstream and can be improved by focusing on communication and planning from the top down.
- Change Failure Rate and Unreviewed PRs: If a high CFR correlates to a high percentage of Unreviewed PRs, leaders should consider adjusting processes to prevent Unreviewed PRs from merging and causing issues.
- Mean Lead Time for Changes and Cycle Time: If MLTC is slow, it could indicate that Cycle Time is too high. Leaders can view these metrics in tandem to check their assumptions, then dig deeper into Cycle Time-related metrics like Time to Open, Time to Merge, and Time to First Review to determine which part of the SDLC is moving slowest.
Using additional metrics to improve performance
Engineering metrics should, first and foremost, be used to ensure that teams have the information they need to learn, reflect, and improve. Once that foundation is in place, teams can use DORA to understand if they’re performing at, under, or ahead of industry standards.
Then, if they want to improve their performance, they can view DORA metrics in context with other SDLC metrics to pinpoint specific areas for growth.
To gain actionable insights by pairing DORA metrics with other key metrics, speak to a Code Climate Velocity specialist.
***
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us here and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.