§ CAPABILITY

DORA Metrics Implementation

Delivery measured from the systems that already record it. Cycle time, deployment frequency, change failure rate and recovery time, reconstructed from your history rather than estimated.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call How the work runs

What you're seeing

A board asked how delivery is trending and the answer was assembled by hand.
Usually means There is no ongoing measurement, so every request for one costs an engineer a day and produces a number nobody can reproduce next quarter.
Two teams report velocity and the numbers cannot be compared.
Usually means Story points are team-local by design. Comparing them measures how each team estimates, which is why the comparison always produces an argument rather than a decision.
Nobody knows how often a deploy causes a problem.
Usually means Change failure rate is unmeasured, so caution is substituting for evidence. It shows up as batching, longer release cycles, and a growing reluctance to ship on a Friday.
A process change was made six months ago and nobody can say whether it helped.
Usually means There was no baseline before it. This is the most expensive consequence of not measuring — improvements and regressions are both invisible, so the same debates recur indefinitely.

Measured, not estimated

The four metrics come out of Git and CI. Nobody points a ticket, nobody fills in a form, and there is nothing for a well-meaning team to round in a favourable direction.

That property is what makes them worth the setup. Estimation-based measures describe how a team estimates, which is a real thing but not the thing anyone wanted to know. Artefact-based measures describe what happened. When the two disagree — and they routinely do — the disagreement is itself a finding worth having.

The first deliverable is a reconstructed baseline covering the previous six to twelve months, because the history is already there. That turns the first report into a trend, which people act on, rather than a single number, which people argue about.

Definitions before collection

The tedious part of this work is agreeing what counts, and skipping it is what makes the numbers worthless later.

Does a configuration change count as a deploy. Does a rollback count as a deploy, as a failure, or as both. Is recovery measured from when the fix merged or from when it was serving traffic. Does a hotfix that bypassed the normal path count at all.

None of these have universally correct answers. All of them have to be answered the same way every time, and written down, or the series breaks silently the first time the tooling changes and nobody notices for a quarter.

The protocol decides whether it lasts

What determines the survival of a metrics programme is not the dashboard. It is the written agreement about what the numbers may be used for.

Used to locate where the delivery system leaks time, they keep working indefinitely and the team helps improve them. Used to compare individuals, or teams with different work, they stop describing reality within a quarter — not because anyone cheats, but because everyone rationally optimises for what is being watched.

So two dashboards get built, deliberately. One for engineering, with enough resolution to investigate. One for the board, with the four numbers and a trend line and no per-team breakdown at all.

Where it sits

This capability sits under Engineering Velocity as the instrument the diagnosis runs on, inside the five-day Engineering Audit as the reconstructed baseline, under CTO Consulting where a velocity sprint needs a before-and-after, and inside Delivery Implementation where it is installed early so the later milestones can be evaluated.

Two neighbours. Board Delivery Reporting is what turns these four numbers into something a non-technical director can read without context. And Process Rebuild is usually what the numbers point at once they exist.

How the work runs

  1. Reconstruct the baseline

    Six to twelve months of history pulled from version control and CI, so the first report shows a trend rather than a single point.

  2. Define the events precisely

    What counts as a deploy, as a failure, as recovered. Ambiguity here is what makes cross-team comparison meaningless.

  3. Instrument for ongoing collection

    Collection wired into the pipeline so the numbers keep arriving without anyone maintaining a spreadsheet.

  4. Set the reading protocol

    Who looks, how often, and what the metric is allowed to be used for — which is the part that decides whether the programme survives.

What arrives

  • A twelve-month reconstructed baseline for the four metrics
  • Automated collection wired into the existing pipeline
  • A dashboard aimed at engineering, and a separate one aimed at the board
  • A written statement of what these numbers may and may not be used for

What it costs your team

Two to three hours of engineering time for access and event definitions. Collection runs itself afterwards.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • The baseline is reconstructed from history before anything is instrumented

    Costs It is more work up front than turning collection on and waiting.

    Version control already contains six to twelve months of the answer. Reconstructing it means the first report is a trend rather than a single point, which is the difference between a number people argue about and a picture people act on. Starting collection today means the first useful reading is two quarters away.

  • No individual's numbers are reported

    Costs It refuses the analysis executives most often ask for.

    Applied to a person, these metrics measure ticket size, and people respond by changing ticket size — at which point the data stops describing anything. The moment a team believes per-engineer measurement is happening, the instrument breaks. A team that trusts the numbers is worth more than any one answer about an individual.

  • The event definitions are written down and agreed before collection

    Costs It is a tedious conversation about what counts as a deploy.

    Ambiguity here is what makes cross-team comparison meaningless. Does a config change count. Does a rollback count as a deploy, a failure, or both. Is recovery when the fix merged or when it was live. Deciding these once, in writing, is what makes the numbers survive a change of tooling.

Frequently Asked Questions

Four measures of software delivery performance: how long a change takes from commit to production, how often you deploy, how often a deploy causes a failure requiring remediation, and how long recovery takes. They come out of version control and CI, so none of them depends on estimation or on anyone filling in a form.
Individually, yes — anyone can raise deploy frequency by deploying nothing. Together they resist it, because frequency bought by skipping review shows up in change failure rate, and a low failure rate bought by never shipping shows up in cycle time. They are read as a set, which is the entire reason there are four.
No, and doing it reliably destroys the data. The metrics describe a delivery system, not a person's contribution. Applied to an individual they largely measure ticket size, and teams respond rationally by changing how work is split. Every organisation that has tried this has ended up measuring its own reporting behaviour.
Then that is the baseline, and the first question is what makes a deploy expensive rather than why the number is low. Low frequency is a symptom worth understanding — usually manual verification, a risky release path, or a batch of changes large enough to be genuinely frightening.
No. These four are system throughput and stability, measured from artefacts. SPACE is a broader framework that includes satisfaction and perceived friction, mostly gathered by survey. They complement each other, and the gap between what a survey says and what the history shows is often the most interesting finding available.

Sources

Page reviewed