How to improve DORA metrics: experiments that move the numbers
You already know your cycle time is 4 days and your change failure rate is 12%. What nobody tells you is how to change those numbers. Here is the loop that does, and twelve example experiments to run it with.
You know the number. It isn't moving.
You probably already own a dashboard: Swarmia, LinearB, Jellyfish, or a DIY board over your Git data. It reports the four DORA metrics: lead time for changes (commit to production), deployment frequency, change failure rate (share of deployments causing a failure), and time to restore service. The definitions are settled; the dashboard computes them nightly.
Then the subscription renews and the numbers are where they were. That is not a flaw in the tool. A DORA metric is the output of team practices: batch size, review wait, what "done" requires, what happens when production breaks. It moves when a practice changes and the change holds. Engineering intelligence tools are the speedometer, which is why they pair with Aurora Coach rather than compete with it.
How Aurora Coach addresses it
Aurora Coach runs a seven-stage improvement loop: Sense, Analyze, Recommend, Refine, Commit, Execute, Re-evaluate. Applied to DORA metrics:
- Sense + Analyze Every team member contributes context. The pattern is inverted: the AI asks structured questions and the team responds. The dashboard supplies the quantitative signal; the team’s words say where the time goes. Aurora Coach does not ingest delivery data unless you integrate it (Aurora Coach for GitHub exists for that), and contextual free-text check-ins keep the signal flowing between sessions. The AI synthesizes the team’s collective context into a SWOT and maturity assessment grounded in the team’s actual situation, combined with industry best practices and academic research across six domains: Foundation, Product, Engineering, Operations, Workflow, and Alignment. DORA work lands in Operations, where the DORA capabilities are treated as practice.
- Recommend + Refine + Commit The AI recommends concrete next steps with rationale, implementation steps, and success criteria, aimed at the constraint the team named. Team members vote; the team lead refines the recommendations to fit the team’s reality; the AI never decides. The team then commits to specific improvements, owned by the team, and commitments are tracked through periods.
- Execute + Re-evaluate The team does the work, in its own context, alongside delivery. Next period’s analysis sees what changed: progress is visible against previous commitments, the loop continues, and context compounds. The dashboard reports the number; the loop changes the practice behind it.
The experiment menu
Twelve examples of commitments a team might make, three per metric. Not best practices to install: starting points a team adapts, owns, and time-boxes in the loop above. Pick one at a time.
Cycle time / lead time for changes
Time from work started to running in production. The dominant constraint is almost always waiting, and the biggest wait is usually review.
- Cap PR size at a max-diff limit the team picks; split anything bigger.
- Start reviews within an agreed number of working hours, or hold a per-reviewer WIP limit the team picks.
- Move to trunk-based development with branches that live less than a day.
Deployment frequency
How often code reaches production. Low frequency is usually a coupling problem: deploys waiting for releases, or for a human gate.
- Ship unfinished work dark behind feature flags so deploys stop waiting for releases.
- Automate or delete the slowest manual gate in the pipeline, watching change failure rate as the guardrail.
- Deploy every green build automatically for one low-risk service.
Change failure rate
Share of deployments causing a failure in production. High CFR means defects pass the checks that exist: change the checks, or shrink the blast radius.
- Tighten the definition of done: tests for the changed behavior, a rollback note, flags default-off.
- Roll changes out to a small slice of traffic first, halting automatically on error spikes.
- End every incident review with one automated test or alert that would have caught it.
Time to restore service (MTTR)
How long a production failure lasts. Restores are slow when they are improvised; these convert improvisation into rehearsal.
- Rehearse the team’s top failure runbooks on a cadence the team picks.
- Name one person per week to own first-response alert triage.
- Practice and time rollback for each deployable service, so restore defaults to rolling back.
How do you improve DORA metrics?
Pick one metric, diagnose the dominant constraint with the team rather than from the dashboard alone, run one time-boxed practice experiment against that constraint, re-measure, and keep or revert. A DORA metric is the output of team practices, so it moves when a practice changes and the change holds. Dashboards locate the problem; they do not run the loop that fixes it.
Which DORA metric should we improve first?
Usually cycle time or lead time, because its constraint is easiest for the team to name (most often review wait), and shrinking batch size tends to help the other metrics too. The exception is a high change failure rate: fix that first, because making a pipeline faster while it ships failures just ships failures faster.
Do DORA dashboards improve performance by themselves?
No. A dashboard is a speedometer: necessary for knowing where you are, incapable of pressing the pedals. The DORA research itself ties performance to capabilities and practices (trunk-based development, small batches, continuous delivery), not to owning a measurement tool. Teams that buy a dashboard and change no practice renew the dashboard a year later with the same numbers.
How long until a metric moves?
Cycle time responds fastest: batch-size and review-wait experiments typically show in the median within two sprints. Deployment frequency moves within weeks of decoupling deploy from release. Change failure rate and time to restore move slowest, because failures are sparse events: expect a quarter of data before trusting the trend. Time-box each experiment anyway; the decision point is what keeps the loop honest.
If cycle time comes up in your next budget conversation, start with MapROI: free, no signup, about 5 minutes, and it produces a tailored ROI analysis for your team setup.