Notes on the scoring curves
lead-time¶
Deploys wait on review, not on build.
Symptoms¶
Finished work sits in a queue. The wait is what people feel; the pipeline is not.
Signals & measures¶
- Median review wait is 14h of a 19h lead time — 74% of elapsed time
- Three approvers required on every change, regardless of size
wait-time¶
Nearly three quarters of elapsed delivery time is a review queue.
Symptoms¶
Finished work is not moving, and the team cannot clear the queue itself. The same delay is raised in retros without an owner, so people experience it as not being heard.
Signals & measures¶
waitTimePct: 74is derived from 14h median review wait ÷ 19h median lead time across the dashboard's 90-day window- Boundary is commit to production; review wait is the only waiting state available in the dashboard, so this is a partial view rather than full flow efficiency
- Confirmed against three of the last four retros; no correction factor applied
deploy-freq¶
The rate is a policy outcome, not a capability limit.
Symptoms¶
Read this next to lead time. The pipeline completes in under an hour; the gap between that and 0.4 deploys a day is queueing, not build capability. Shipping less often than they can is experienced as stuckness, not as a careful release policy.
change-fail¶
A low failure rate on a low change rate is not the same result as a low failure rate on a high one.
Symptoms¶
Read this one beside deployment frequency. The rate looks healthy, and part of why is that the risky work is not being attempted — large changes are batched until they can be approved together. A quiet failure number here is not the same as confidence that a change will land.
Signals & measures¶
- Assumes the dashboard reports change-failure rate as a fraction (
0.12entered as 12%). Unlabelled on the dashboard; to be confirmed with the platform team - Same dashboard: 0.4 deploys/day, so the failure rate is on a low change rate, not a high one
recovery-time-cqa¶
Recovery depends on who is on call, so the spread matters more than the median.
Symptoms¶
The night goes well or badly depending on who answered. That is the opposite of calm: the rota is a lottery over knowledge that was never written down.
Signals & measures¶
- Assumes MTTR is reported in minutes;
45entered as 0.75h - No runbook for the two most frequent alerts, so time-to-diagnose dominates time-to-fix
recovery-time¶
Same reading, service-quality lens.
Symptoms¶
Recovery time feeds two signals, so it needs a note under each curve to appear
under both. This is the QoS one; recovery-time-cqa carries the change-quality
one. From inside the organisation it is the same night: wait to find out who
is on call, then wait while they diagnose.
medhigh-incidents¶
Six a month across three teams is two per team, which is where this curve turns steep.
Symptoms¶
Customer-affecting incidents at this rate leave little room between pages. The load is felt as always being on, even when the median recovery time looks contained.
Signals & measures¶
teamsCount: 3supplied, so the per-team division is right. Without it the group would be scored as one team and read far worse