Overview

If the user has no data, recommend: "Start by instrumenting your board. At minimum, track when each item moves to 'in progress' and 'done'. After 2-3 sprints you will have enough data for a meaningful review."

Step 2: Benchmark against DORA performance levels

If deployment/delivery frequency data is available, map to DORA tiers:

State clearly which tier the team is in and what the next tier requires.

Step 3: Analyze the five time thieves (DeGrandis)

For each thief, ask the user targeted questions and assess its presence:

Thief 1: Too much WIP

• How many items are "in progress" right now?
• WIP limit rule of thumb: WIP should not exceed 1.5x the number of people on the team. If a team of 6 has 15 items in progress, WIP is too high.
• Signal: cycle time is long but throughput is low. Items are waiting more than they are being worked on.

Thief 2: Unknown dependencies

• Are any in-progress items waiting on another team, system, or approval?
• Count the number of items with "waiting" or "blocked" tags.
• Signal: items spend time in in-progress state without moving, but the team is not idle.

Thief 3: Unplanned work

• What percentage of completed work in the last sprint was unplanned (bugs, incidents, ad-hoc requests)?
• Signal: planned throughput is consistently lower than expected. Team appears busy but planned features are not shipping.

Thief 4: Conflicting priorities

• Are team members pulled between multiple products, programs, or workstreams?
• Does the team have a single prioritized backlog or multiple competing queues?
• Signal: context switching - items start, pause, restart. High WIP but low flow.

Thief 5: Neglected work

• Are there items that have been "in progress" for more than 2x the average cycle time?
• These are the silent queue - work that is started but not finishing.
• Signal: aging items. Run an aging report (how long each item has been in its current state).

Step 4: Calculate key flow metrics

Using the data the user provides:

Cycle time = average time from "in progress" to "done"

• Calculate average, p50 (median), and p85 (85th percentile)
• p85 is your service level agreement - 85% of items complete within this time
• A healthy cycle time has low variance. High variance means unpredictable delivery.

Throughput = items completed per sprint or week

• Calculate average throughput over the last 4-6 sprints
• Throughput trend: increasing, stable, or declining?

WIP age distribution

• How many items have been in progress 0-3 days / 4-7 days / 8-14 days / 14+ days?
• Items in the 14+ day bucket are flow blockers requiring immediate attention.

Flow efficiency (if data allows)

• Flow efficiency = active work time / total cycle time
• Industry average is 15-40%. Below 15% means the work is waiting more than it is being worked on.

Step 5: Generate the flow metrics report

FLOW METRICS REVIEW - [your team/program]
Period: [date range]
Data source: [Jira / Linear / manual]

DORA PERFORMANCE TIER: [Elite / High / Medium / Low]
- Deployment frequency: [value] ([tier])
- Lead time: [value] ([tier])
- Change failure rate: [value] ([tier])
- MTTR: [value] ([tier])

FLOW HEALTH SUMMARY
Cycle time (p50): [N] days
Cycle time (p85): [N] days  <- your de facto SLA
Throughput: [N] items/sprint (trend: [up/stable/down])
Current WIP: [N] items (team size: [N], recommended max: [1.5x team size])
Flow efficiency: [N]% [if calculable]

TIME THIEF ANALYSIS
[Thief]: [Present / Not detected] - [1-sentence evidence]
[Thief]: [Present / Not detected] - [1-sentence evidence]
[Thief]: [Present / Not detected] - [1-sentence evidence]
[Thief]: [Present / Not detected] - [1-sentence evidence]
[Thief]: [Present / Not detected] - [1-sentence evidence]

TOP 3 BOTTLENECKS
1. [Bottleneck]: [evidence] - Recommended action: [specific action]
2. [Bottleneck]: [evidence] - Recommended action: [specific action]
3. [Bottleneck]: [evidence] - Recommended action: [specific action]

RECOMMENDED EXPERIMENTS (pick one to try next sprint)
- [Specific change]: expected impact on [metric]

Step 6: Recommend one experiment

Do not give a list of 10 improvements. Pick one experiment based on the biggest bottleneck identified. Format:

EXPERIMENT: [name]
Hypothesis: If we [action], then [metric] will improve by [amount] because [reasoning].
How to measure: Track [metric] before and after for [N] sprints.
Owner: [name]
Start: [date]
Review: [date]

Anti-Patterns

1. Reporting metrics without interpreting them Bad: "Cycle time is 8.3 days." Good: "Cycle time is 8.3 days (p85: 14 days). The spread between p50 and p85 is high - it signals that a subset of items are regularly getting stuck. Likely cause: unknown dependencies."

2. Focusing on velocity instead of flow Bad: "Our velocity dropped from 42 to 38 story points this sprint." Good: Velocity measures effort, not flow. Cycle time and throughput measure whether work is actually moving. Use flow metrics to diagnose, velocity to plan.

3. Too many WIP items treated as a productivity signal Bad: "The team has 18 items in progress - they are really busy." Good: 18 items in progress for a team of 8 is 2.25x the recommended limit. High WIP is the cause of slow cycle time, not a sign of productivity.

4. Ignoring aging work Bad: Status report that only shows items completed this sprint. Good: Flag any item that has been in-progress for more than 2x the average cycle time. These are hidden blockers.

5. Recommending many improvements at once Bad: 8-point action plan to improve flow. Good: One focused experiment. Changing too many variables at once makes it impossible to know what worked.

Quality Checklist

• DORA tier is assessed for all four metrics (or gaps noted)
• All five time thieves are assessed - presence or absence stated with evidence
• Cycle time is reported as p50 and p85, not just average
• WIP count is compared to team size (1.5x rule)
• Aging items (14+ days in-progress) are called out specifically
• One specific experiment is recommended with a hypothesis and measurement plan
• Report distinguishes diagnosis (what the data shows) from prescription (what to do)