"Are we getting better at delivering software?" is a surprisingly hard question to answer. Teams reach for story points, ticket counts, or lines of code, and those measures reward activity rather than outcomes. A team can close a hundred tickets and still ship slowly, break production weekly, and burn out its engineers.
The DORA metrics are the most widely used attempt to fix this. They come from years of research by the DevOps Research and Assessment program — now part of Google Cloud — and were popularized by the book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim. The core finding: a small set of delivery measurements correlates with how well a technology organization performs overall.
The four metrics
Deployment frequency — how often your team successfully releases to production. More frequent, smaller releases are generally easier to test, understand, and roll back.
Lead time for changes — how long it takes a change to go from committed to running in production. It reveals bottlenecks: slow reviews, long test suites, manual approvals, infrequent release trains.
Change failure rate — the percentage of deployments that cause a failure in production requiring remediation, such as a rollback, hotfix, or incident.
Time to restore service — how quickly you recover when something breaks. Recent DORA reports have refined this to focus specifically on recovering from failed deployments, and have also explored adding a measure of unplanned rework. Check the latest report for current definitions.
The first two measure throughput; the second two measure stability. The central insight of the research is that these don't trade off against each other: high-performing teams are both faster and more stable, because small, well-tested, automated changes are safer than big, rare ones.
Collecting them from tools you already have
You don't need a new platform to begin. Most of the data already exists in your version control, CI/CD, and incident tools.
# Deployment frequency: list production deployments from GitHub
gh api repos/OWNER/REPO/deployments --paginate \
--jq '.[] | select(.environment=="production") | .created_at' \
| cut -c1-10 | sort | uniq -c| Metric | Typical data source |
|---|---|
| Deployment frequency | CI/CD pipeline runs, deployment events |
| Lead time for changes | Timestamp of commit or merge, versus timestamp of production deploy |
| Change failure rate | Deployments linked to incidents, rollbacks, or hotfix releases |
| Time to restore | Incident tracker: opened to resolved |
Start crude. A spreadsheet fed by weekly exports is enough to see the shape of your delivery, and imperfect-but-consistent measurement beats a perfect dashboard that never gets built. Be explicit about definitions — what counts as a "deployment," when "lead time" starts — and don't change them midstream, or you'll chart definitional drift rather than progress.
How the metrics get gamed (and ruined)
Any measure used as a target tends to get distorted — a pattern known as Goodhart's law. Watch for these:
- Ranking teams against each other. Different systems have different constraints. A team running a regulated medical device and one shipping a marketing site shouldn't be compared directly. Use the metrics to track each team's own trend.
- Setting the number as a goal. "Deploy ten times a day" invites trivial deploys to hit the quota. The goal is better delivery; the metric is a signal about it.
- Using them to evaluate individuals. These are team and system measures. Individual scorecards destroy trust and encourage hiding failures.
- Hiding failures to protect change failure rate. If reporting an incident makes the number worse, people stop reporting. Make failure data safe.
- Optimizing one metric alone. Raising frequency while stability craters isn't improvement. Always read the four together.
What the numbers are telling you
The value is in the diagnosis, not the score:
| Symptom | Likely cause to investigate |
|---|---|
| Long lead time, low frequency | Large batches, slow review, manual approvals, flaky or slow tests |
| High change failure rate | Weak automated testing, missing staging parity, big risky releases |
| Long time to restore | Poor observability, no rollback path, unclear on-call ownership |
| Frequent deploys with high failures | Speed without enough quality gates |
This is where DORA connects to the daily mechanics of pipelines. If your pipeline is slow or untrusted, lead time and frequency suffer; see CI/CD pipelines that developers actually trust, and for the automation side, building reusable GitHub Actions workflows.
A practical way to start
- Pick one team willing to experiment, not the whole company.
- Define the four metrics in writing, with sources.
- Collect four to six weeks of baseline, with no targets.
- Review the numbers together in a retrospective, looking for the biggest bottleneck.
- Change one thing, such as shrinking batch size or automating one manual gate, and watch what moves.
- Share the learning, not a league table.
Metrics need capability behind them
The research also identifies technical and cultural capabilities that drive these outcomes: continuous integration, trunk-based development, test automation, loosely coupled architecture, monitoring, and a blameless culture. Numbers show where you stand; skills and practices move them.
Our CI/CD Pipeline Design and Implementation course builds the delivery side, and Site Reliability Engineering Fundamentals covers the stability side, including reliability targets as explained in our SLO and error budget guide. Want to benchmark your own team? Talk to us.