BlueOptima and DORA Metrics
Last updated on October 12, 2026 • Approximate read time: 4 minutes
This page is available without a BlueOptima account.
DevOps Research and Assessment (DORA) metrics are a widely used way to benchmark how an organization deploys software. They measure deployment speed and stability. They do not measure how much work goes into the code or how maintainable that code is. BlueOptima measures both, directly from source code changes.
This page explains what each set of metrics measures, and what BlueOptima's research says about relying on delivery speed alone.
What DORA Metrics Measure
DORA defines four metrics that benchmark how an organization deploys software.
- Deployment Frequency: how often an organization successfully releases to production.
- Lead Time for Changes: how long it takes a commit to reach production.
- Change Failure Rate: the percentage of deployments that cause a failure in production.
- Time to Restore Service: how long it takes an organization to recover from a failure in production.
These are retrospective measures of the deployment process. They show how fast and how reliably software ships. They are not measures of productivity or code quality.
What BlueOptima Measures
BlueOptima measures the development work that comes before deployment, directly from source code changes. It covers three areas.
- Productivity: Coding Effort weighs the volume, complexity, and interrelatedness of every change using 36 static metrics. It supports pull request analysis, task tracker integration for sprint-level efficiency, and standardized comparisons across projects, teams, vendors, and locations.
- Maintainability: how easy or difficult it is for a developer to contribute to unfamiliar source code.
- Cost efficiency: benchmarked cost data pooled across industries, showing what it costs to deliver a unit of change to a codebase.
Because these measures come from the code itself, they do not depend on how a team's release workflow is set up.
| Aspect | DORA Metrics | BlueOptima |
|---|---|---|
| Question it answers | How fast and how reliably does software ship? | How much effort goes into the code, how maintainable is it, and what does it cost? |
| Where it measures | Deployment and production | Source code changes and pull requests |
| Where the data comes from | Continuous integration and continuous delivery (CI/CD) tools, task tracking, and incident systems | Source code repositories and task trackers |
What Our Research Found About Speed
BlueOptima tested whether a faster Lead Time for Changes goes with higher productivity or better code quality. The study, published in the white paper DORA Lead Time To Change (LTTC): Useful but Inadequate, analyzed a dataset of more than 600,000 developers, with workflow analysis on a subset of 30,000 developers across 30 enterprises. It used three years of pull request data, from 2020 to 2022.
The study found the following.
- There was no direct correlation between faster lead time and higher coding output or quality.
- Pull requests merged within one day showed lower Billable Coding Effort (BCE) per day than pull requests merged in one to seven days.
- Pull requests merged within five minutes of creation, which the paper calls Lightning pull requests, were more common in the fastest group. The paper reads this as a possible sign of speed taking priority over thoroughness.
- The fastest group also had the best maintainability results. The paper suggests this is because its changes were largely trivial, which makes good maintainability results easier to achieve.
The study measures time to merge, not time to deploy to production. The paper also states that the correlations between the share of Lightning pull requests and both productivity and quality are not statistically significant. Read the results as evidence that speed alone is an incomplete measure, not as proof that faster delivery lowers performance.
How Code Quality Relates to Stability
Change Failure Rate and Time to Restore Service show that failures happened and how long recovery took. They do not show where risk builds up in the code.
BlueOptima's 2026 research on software incident risk analyzed more than 666,000 source code revisions across 13 enterprises. Incidents in the least maintainable quartile of code took a median of 65.2 hours to resolve, compared with 1.7 hours in the most maintainable quartile.
📚 See: BlueOptima and Coding Effort FAQs, in the section on ART scores, for a summary of the study.
Balance Speed With Quality
Whatever delivery metrics you track, a few practices follow from the research.
- Pair speed with quality. Read Deployment Frequency and Lead Time for Changes next to a code quality measure, so a faster number is never the only signal.
- Add guardrails to very fast workflows. Controls such as peer review and testing keep rapid loops from trading away quality.
- Balance workflow-based metrics with measures taken from the code. This guards against teams optimizing a single number.
When delivery is slow, Code Delivery in BlueOptima shows where work waits between first commit, review, and production, with a drill-down into individual commits and pull requests.
📚 See: Code Delivery. 🔒 Requires a BlueOptima account.
Talk to the BlueOptima Team
If you want to see how BlueOptima measures productivity and quality in your own codebase, book a demo.
📚 Related: Why You Can Trust BlueOptima's Metrics