DORA scorecard vs benchmarks

I want to know where we really stand on DORA, which of the four metrics is holding us back, and what to do about that one. ## Context - Scope: [all squads | squad name] - Period: [last 90 days], compared with the 90 days before it - What the business complains about most: [nothing specific | things take too long | things break | both] - If I left anything in [brackets], keep what reads as a default (a period, a number of days, the first of several options) and ask me for the rest in one go, before pulling any data. - Write everything, the deliverable included, in the language of this prompt. ## Pull this data from DevStats (both periods, same filters) 1. DORA Metrics — PR cycle time, deploy frequency, MTTR, change failure rate 2. Deploy — deploy count 3. Benchmarks — the tier for each metric 4. PR Cycle Time — coding / pickup / review / deploy breakdown 5. Code Review — average PR size, PRs merged without review ## How to analyze - The four metrics are two pairs: speed (lead time, deploy frequency) and stability (change failure rate, MTTR). Read them as pairs. Elite speed with low stability is not elite, it is breaking things quickly. - A change failure rate of 0% or an MTTR of zero almost always means incidents are not being recorded, not that nothing failed. Check whether incident data exists before celebrating, and say so plainly if it does not. - Deploy frequency is a consequence of batch size. If it is low, look at PR size and at the deploy stage of cycle time before asking anyone to "deploy more". - For lead time, name the stage that owns most of it. Pickup and review are team habits. Deploy is pipeline and release process. They need different fixes. - Benchmark tiers are wide bands. A Medium that improved 30% is a better story than a High that is sliding. Report the movement, then the tier. - Do not chase Elite on all four. Pick the metric that constrains the business: if the complaint is slowness, lead time; if it is breakage, change failure rate. - Match practices to evidence. Large PRs call for a size limit and smaller slices. Long deploy stage calls for pipeline work and feature flags. High failure rate calls for tests on the paths that failed and automated rollback. Do not recommend a practice the data does not ask for. - A stage that comes back blank in one period (deploy time is the usual one) was not tracked; it did not take zero time. The totals of the two periods are then not comparable: compare the stages both periods have, and say so. ## Deliver A one-pager: 1. **Scorecard** — table: metric, current, previous, change, benchmark tier, and what it means in one line 2. **Speed vs stability** — two sentences on how the pairs read together 3. **The one to fix first** — which metric, why that one, and the number to aim for next quarter 4. **Three practices** — each tied to the evidence that calls for it, with the smallest first step 5. **Data caveats** — anything missing or suspicious, especially incident data