# DORA scorecard — all squads

Last 90 days, compared with the 90 days before. Business complaint going in: both "things take too long" and "things break". Source: DevStats MCP.

## 1. Scorecard

| Metric | Now | Before | Change | Tier | What it means |
|---|---|---|---|---|---|
| Lead time (PR cycle time) | 1d 20h | 1d 6h | looks worse, is not (see below) | High (was Elite) | Like for like it fell 24%: 22h 12m vs 29h 14m |
| Deploy frequency | every 0.2 days, 513 deploys | every 0.3 days, 342 deploys | 50% more deploys | Elite (was Elite) | Shipping is a non-event here |
| Change failure rate | 3.1% | 4.4% | better | no tier returned | About 16 failed deploys, 15 before: same failures, more deploys |
| **Time to recovery** | **5d 10h** | **3d 21h** | **40% slower** | no tier returned | A failure now takes three times longer to fix than a normal change takes to ship |

## 2. Speed vs stability

**Speed is strong and getting stronger.** Deploys went up 50%, PRs merged per developer per week went from 3.77 to 9.28, and the part of lead time the team controls (coding, pickup, review) fell from 29h 14m to 22h 12m. The move from Elite to High on lead time is a measurement change: the previous period recorded no deploy stage, this one records 18h 3m of it.

**Stability is the weak pair, and only half of it.** We do not break things more often (3.1% of deploys, down from 4.4%). We are slow to fix them when we do: 5d 10h, up from 3d 21h. Fast delivery with a five-day recovery is not elite. It means a customer who hits a failure waits most of a week.

## 3. The one to fix first: time to recovery

Why this one and not lead time, when the business complains about both:

- Lead time is already improving on its own, and deploy frequency is Elite. The "takes too long" complaint is not coming from the delivery pipeline.
- Recovery is the only one of the four that got worse, and it got 40% worse.
- 5d 10h to recover against 1d 20h to ship a normal change means fixes are moving slower than features. A fix is a change. It should be the fastest thing in the pipeline, not the slowest.

**Number to aim for next quarter:** first get recovery back under 3d 21h, where it was. Then under 1d 20h, so that a fix never takes longer than ordinary work. With roughly 16 failures in 90 days this is a small number of incidents. Each one handled well moves the average visibly.

## 4. Three practices

**1. Give failures an owner and a fast path.**
Evidence: recovery is three times the normal lead time, so failed changes are waiting in the same queues as everything else, or in a worse one. Pickup alone is 14h 56m and has not moved in two periods (14h 14m before).
Smallest first step: list the roughly 16 failures of the period with open and close dates, and find where the five days went on the three longest. The pattern will be in those three.

**2. Make recovery a deploy, not a fix.**
Evidence: merged code waits 18h 3m to reach production, the largest single stage of lead time. If the way out of a failure is a new fix going through that same path, recovery can never be faster than it. Rollback and feature flags turn recovery into a switch.
Smallest first step: for the next feature that ships, put it behind a flag and write down how to turn it off. Measure whether the next failure is resolved by the switch.

**3. Keep review from thinning out while speed goes up.**
Evidence: review time halved (8h 5m to 3h 52m) and PRs got 26% smaller (419 to 311 lines), which is good. But comments per review fell from 1.33 to 0.41, review depth from 4.1 to 0.65 comments per PR, and PRs merged without any review went from 1 to 6. Failure rate has not paid for this yet. It is the leading indicator that it will.
Smallest first step: look at the 6 PRs merged without review. If any of them is among the failures, that is the rule to add: nothing reaches production unreviewed.

Not recommended, because the data does not ask for it: a PR size limit (size is already falling on its own) and "deploy more often" (deploy frequency is Elite).

## 5. Data caveats

- **Lead time is not comparable across the two periods.** PR Cycle Time returned no deploy stage ("-") for the previous 90 days and 18h 3m for the current period. The reported totals (1d 6h vs 1d 20h) mix two definitions. The like-for-like numbers in the scorecard add coding, pickup and review only.
- **Incident data exists only at organization level.** Org-wide the tool returns a 3.1% failure rate and 5d 10h recovery. Filtered by squad, App, Support and GTM each return 0% and 0. That zero means failures are not attributed to squads, not that no squad had one. I cannot say which squad owns the recovery problem.
- **App and Support return identical DORA numbers** (1d 21h lead time, 513 deploys). They share one repository, so per-squad DORA cannot tell them apart. GTM shows no deploys tracked.
- **Benchmarks returns no tier for change failure rate or time to recovery**, only for lead time and deploy frequency. The stability pair is judged here on its own movement, not against an industry band.
- The failure counts (about 16 and 15) are the failure rate multiplied by the deploy count. The tool does not return the incidents themselves.