flow-metrics-interpreter

Flow Metrics Interpreter

A dashboard of cycle time and throughput is useless until someone says what it means — is the flow healthy, where's it clogging, and what should the team try Monday. This reads the metrics together (they only make sense in relation), points at the likely bottleneck, and proposes specific experiments — while flagging the classic trap of optimising the number instead of the flow it's meant to measure.

What This Skill Produces

• The health read — per metric (cycle time, throughput, WIP, aging), what "good" looks like and where you are
• The bottleneck the numbers point to — read together, where work is actually stalling
• 2–3 process experiments — concrete, small, reversible things to try next (with what to watch)
• The gaming trap — how this metric gets optimised dishonestly, so you don't

Required Inputs

Ask for these if not provided:

• The metrics — cycle time (distribution, not just average), throughput per period, current WIP, and any aging/stuck items
• The baseline — a few periods of history if you have it (a single number can't show a trend)
• Team context — team size, work type, and any recent changes (reorg, new process, holidays) that explain a shift
• What prompted this — a felt slowdown, a planning question, a stakeholder asking

Framework: Read the Flow, Not the Number

1. Distributions over averages. Cycle time's spread and tail (the 85th percentile) matter more than the mean — averages hide the pain.
2. Read metrics together. Rising cycle time + flat throughput + high WIP = you're starting too much, not finishing. One metric alone lies.
3. WIP is the lever. Little's Law: cycle time ≈ WIP ÷ throughput. Too much in progress is the most common, most fixable cause of slow delivery.
4. Aging is the early warning. Items aging past their usual cycle time are today's problem; end-of-sprint is too late to notice.
5. Baselines beat targets. Compare to your own trend, not an industry number; a "good" cycle time is context-specific.
6. Watch for gaming. Any metric made a target gets gamed — smaller tickets to shrink cycle time, etc. Name it.

Output Format

Flow read — [team] · [period]

| Metric | Reading | Health |

|---|---|---|

| Cycle time (p50 / p85) | … | 🟢🟡🔴 |

| Throughput | … | |

| WIP | … | |

| Aging (items past usual) | … | |

What the numbers point to: [likely bottleneck, from reading them together].

Experiments to try (pick 1–2)

1. [e.g. set a WIP limit on 'In Review'] — watch: [what should move].

Don't game it: [how this metric gets faked, and the honest alternative].

Quality Checks

• [ ] Cycle time is read as a distribution (p85/tail), not just an average
• [ ] Metrics are interpreted together, not in isolation
• [ ] WIP / Little's Law is considered as the likely lever for slow flow
• [ ] Aging/stuck work is surfaced as the early signal
• [ ] Comparison is to the team's own baseline, not an arbitrary target
• [ ] The gaming trap for the recommended metric is named

Anti-Patterns

• Restating the numbers without interpreting them.
• Averages only — hiding the painful tail of cycle time.
• One metric in isolation — throughput without WIP tells you nothing about health.
• Industry-target worship — "cycle time should be 3 days" ignores your context.
• Recommending a metric as a target without warning how it gets gamed.

Example Trigger Phrases

• "Interpret our cycle time and throughput — is delivery healthy?"
• "What do these Actionable Agile metrics actually mean for us?"
• "Why does our delivery feel slow? Here are our flow numbers."
• "Read our Kanban metrics and suggest experiments."
• "Our WIP is high and cycle time is climbing — what do we do?"