The scorecard in Chapter 12 gives you the ten numbers on one page. This appendix tells you how each one is built, so anyone running your delivery can compute it the same way twice. Four of the ten come straight from the DORA four key metrics (DORA, 2024): lead time for changes, change-failure rate, time to restore, and (by extension) the delivery rhythm those metrics assume. The rest are the measures a non-technical founder can read without learning to run a sprint.
A note on "what good looks like." Where a public benchmark exists and is sourced, the table names it. Where one doesn't, the column gives you a direction of travel rather than a borrowed number, because a made-up target is worse than an honest one. The point of a KPI isn't to hit somebody else's figure. It's to make a hidden thing visible and give one person the job of moving it.
The ten, at a glance
| # | KPI | Accountability it serves |
|---|
| 1 | Lead time for changes | Software delivery |
| 2 | Delivery predictability | Software delivery |
| 3 | Cycle time per task | Team performance |
| 4 | Bus-factor / key-person concentration | Team performance |
| 5 | Change-failure rate | Operational reliability |
| 6 | Time to restore (MTTR) | Operational reliability |
| 7 | Defect escape rate | Technical quality |
| 8 | Rework ratio | Technical quality |
| 9 | % of work tied to a business outcome | Roadmap & business alignment |
| 10 | Roadmap commitment accuracy | Roadmap & business alignment |
Lead time for changes
| |
|---|
| What it is | The clock from "a change is started" to "that change is live in front of users." A DORA key metric (DORA, 2024). |
| How to measure | Timestamp when work begins on a change and when it reaches production. Take the median over a rolling window, not the average — one slow item shouldn't move the headline. |
| What good looks like | Short and steady. Trending down over a quarter matters more than any single figure. If lead time is measured in weeks, your delivery has a queue you can't see. |
| Serves | Software delivery. |
Delivery predictability
| |
|---|
| What it is | How closely what you said you'd ship matches what you actually shipped, over a defined window. The honesty check on the cadence. |
| How to measure | At the start of each cycle, record what was committed. At the end, record what shipped. Predictability = delivered ÷ committed, tracked over time. Count only work that met its definition of done. |
| What good looks like | High and stable, without padding the commitment to game it. A team that promises little and delivers it isn't predictable. It's quiet. |
| Serves | Software delivery. |
Cycle time per task
| |
|---|
| What it is | How long one task takes from "picked up" to "shipped." Lead time looks at the whole change; this looks at the unit of delivery, the task. |
| How to measure | Per task, log the time from in-progress to done. Report the median and the spread. A tight spread tells you the work is genuinely task-shaped; a wide one says some "tasks" are really projects in disguise. |
| What good looks like | Consistent, with few outliers. When most tasks land inside a narrow band, capacity becomes something you can forecast instead of guess. |
| Serves | Team performance. |