What DORA metrics are — and why every engineering leader gets asked about them
DORA metrics come from the DevOps Research and Assessment program, the largest long-running study of software delivery performance. Its research reduced “are we good at shipping software?” to four measures that together capture both speed and stability. They matter because they are the closest thing engineering has to an industry-standard scorecard: boards ask for them, platform teams are targeted on them, and the annual State of DevOps report benchmarks them across thousands of organisations.
- Deployment frequency — how often you successfully release to production. Elite performers deploy on demand, multiple times per day.
- Lead time for changes — how long it takes a change to go from started to running in production. Elite: under a day.
- Change failure rate — what share of changes cause a failure that needs remediation. Elite: roughly 0–15%.
- Time to restore service — how quickly you recover when something does fail. Elite: under an hour.
Why Azure DevOps doesn’t show them out of the box
Azure DevOps has all of the raw ingredients — Pipelines knows about every build and release, Boards knows the full history of every work item — but no built-in view assembles them into DORA metrics. The native Analytics views and dashboard widgets cover velocity, burndown, and cumulative flow; deployment-centric measures are absent. So teams that want DORA numbers in ADO typically end up on one of three paths, each with a real cost.
Path 1: build it yourself in Power BI or the API
The Azure DevOps OData feed and REST API expose the underlying data, and a determined engineer can join pipeline runs to work-item history in Power BI. It works — but it is a project, not a report: authentication, schema drift between projects, deciding what counts as a “deployment”, and a dashboard someone now owns forever. Most versions of this quietly die within two quarters.
Path 2: an external engineering-intelligence platform
Platforms like LinearB, Swarmia, or Jellyfish compute DORA metrics well — by ingesting a copy of your development data into their cloud, at price points set for enterprise budgets. For many organisations the blocker isn’t money but data governance: security review of a third party holding your full delivery history, for four numbers.
Path 3: measure them natively, inside Azure DevOps
The newest option is an extension that computes DORA metrics inside your Azure DevOps organisation, reading the same work items and pipeline runs you already have, rendering the numbers in a hub next to your boards — with nothing exported anywhere. That is what Agile Analytics does, and the rest of this guide shows how each metric is derived so you can trust (and interrogate) the numbers whichever path you choose.
Deployment frequency: count successful pipeline runs honestly
The cleanest source in Azure DevOps is completed pipeline runs. Pick the window you care about (say 30 days), count successful runs of the pipelines that actually deploy, and normalise per week. Two honesty rules make the number meaningful: count only pipelines that deploy (not CI-only builds), and keep the window explicit — “9 deploys per week over the last 30 days” invites the right follow-up question, while a bare “9” invites arguments. In Agile Analytics this is the Deployment Frequency card in the DORA Metrics view: it reads your completed pipeline runs over a 14, 30, or 90-day window through Azure DevOps’ read-only Build scope, and shows the run count behind the rate.
Lead time for changes: your work items already know it
Formally, lead time for changes measures commit-to-production. If your deployments are tagged and traceable end to end, you can compute exactly that. Most teams aren’t there — and there is a pragmatic, defensible proxy in the data you already keep: the time from when a work item became active to when it closed, measured across recently completed delivery items. It tracks the same underlying reality (how long changes take to get done and shipped) and improves under exactly the same actions: smaller batches, less waiting, faster review. The important discipline is labelling: report it as a work-item proxy with its percentiles and sample size — “P50 4.2 days across 38 items” — never as a bare number pretending to be commit-level truth. That is precisely how the DORA Metrics view presents it.
Change failure rate and time to restore: defect signals as the proxy
A change “fails” when it needs remediation — a hotfix, a rollback, an incident. In work-item terms, the closest widely-available signal is bugs opened against the volume of changes delivered in the same window: a defect-rate proxy for change failure rate. Time to restore, similarly, can be proxied by how quickly bugs get from opened to closed — P50 and P85, not averages, because one week-long outlier shouldn’t define your story. These proxies are imperfect and honest about it: they move in the right direction when the real thing improves, they cost you zero instrumentation, and they give you a baseline today rather than after a quarter of tagging discipline.
What “good” looks like — and the trap to avoid
The DORA research clusters performers into bands: elite teams deploy on demand with lead times under a day, sub-15% change failure rates, and sub-hour recovery; low performers deploy monthly or slower with lead times measured in months. Use the bands for orientation, not judgement — the research’s own authors are emphatic that DORA metrics are a compass, not a leaderboard. The trap: the moment any one metric becomes a target, it gets gamed (deploy frequency by splitting releases, CFR by reclassifying bugs). The defence is to always read the four together — speed metrics and stability metrics keep each other honest — and to watch trends over quarters rather than absolute values over sprints.
Getting DORA metrics in Azure DevOps in five minutes
If you’d rather not build Path 1 or procure Path 2, the native route takes about five minutes end to end.
- Install Agile Analytics from the Azure DevOps Marketplace (free 30-day trial, no card).
- Have an organisation admin approve the extension’s permissions — including the read-only Build scope that unlocks pipeline-based deployment frequency.
- Open Boards → Agile Analytics → DORA Metrics, pick a team and a 14/30/90-day window.
- Read the four cards: deployment frequency and build failure rate from your pipelines; lead time and time to restore from your work-item history, each labelled with its sample size.
Your data never leaves Azure DevOps
One architectural point worth understanding whichever tool you evaluate: where does the computation happen? Agile Analytics computes every metric inside your Azure DevOps session, using read-only scopes, and stores nothing outside your organisation — there is no ingestion pipeline, no copy of your backlog in someone else’s cloud, and nothing for a security review to chase. For regulated teams this is usually the difference between “installed this afternoon” and “blocked in procurement for a quarter”.
Related: Agile Analytics for Azure DevOps — overview · Azure DevOps reporting, board-ready · What shipped in 6.26 — DORA Metrics, Exec Report, Investment Allocation