Cycle Time Analyzer (Flow Metrics)

Overview

Compute and visualize the four core Kanban flow metrics -- lead time, cycle time, throughput, and work-in-progress -- from issue history data exported from Jira, Linear, GitHub Projects, or any tracker that records status transitions. The output is a dashboard suitable for sprint retrospectives, executive reporting, and bottleneck analysis, plus a Mermaid cumulative flow diagram that visualizes work accumulation over time.

Flow metrics are the most useful diagnostic for team and process health, far more so than velocity or story points. Daniel Vacanti's body of work (notably Actionable Agile Metrics for Predictability, 2015) makes the case that a team's predictability and throughput are governed by Little's Law (Throughput = WIP / Cycle Time), and that the most reliable way to improve delivery is to lower WIP and stabilize cycle time -- not to estimate harder.

This skill ingests a JSON file of issues with status transition history and produces all four flow metrics plus aging WIP (the work-in-progress that is older than the team's 85th percentile cycle time -- the items most at risk). All outputs support the shared --format schema (json, markdown, mermaid, confluence, notion, linear).

When to Use

• Sprint retrospective -- A team wants data-driven discussion of why some sprints feel slow.
• Bottleneck investigation -- Throughput has fallen and the team needs to identify the constraining step.
• Quarterly delivery review -- Leadership wants a real picture of delivery performance beyond story-point velocity.
• Predictability analysis -- Stakeholders want delivery forecasts grounded in actual cycle time distributions (use with Monte Carlo via scrum-master/).
• WIP-limit calibration -- A Kanban team is setting WIP limits and needs a baseline of current behavior.

When NOT to Use

• For story-point velocity tracking, use scrum-master/velocity_analyzer.py.
• For sprint capacity calculation, use scrum-master/sprint_capacity_calculator.py.
• For per-person performance evaluation -- flow metrics are team-level signals; using them to rank individuals destroys the team behavior they measure.

The Four Flow Metrics (Vacanti)

1. Lead Time

The total elapsed time from the moment a work item is committed (created or moved out of backlog into "Ready") to the moment it is delivered (closed / deployed / accepted).

Lead time is the customer's view: "how long from when I asked to when I got it?"

2. Cycle Time

The elapsed time from when work actively started (item moves to "In Progress") to delivery. Cycle time excludes time the item sat in "Ready" or "To Do."

Cycle time is the team's view: "how long does it take us to finish what we start?"

Always report cycle time as a distribution (50th, 85th, 95th percentile), never as an average. Averages hide variability and lead to over-confident commitments.

3. Throughput

The count of items completed per unit time (typically per week or per sprint). Throughput is the team's delivery rate.

Throughput is more reliable than story-point velocity because it counts atomic units (one completed thing = one), avoiding estimation bias.

4. Work-In-Progress (WIP)

The count of items started but not yet finished at a point in time. WIP includes everything in any "in flight" state (In Progress, In Review, Blocked, etc.).

Little's Law

The relationship that ties the four together (John D. C. Little, 1961):

Average Cycle Time = Average WIP / Average Throughput

The practical implication: the fastest way to reduce cycle time is to reduce WIP. Working on fewer things at once forces finishing before starting and exposes the bottlenecks.

Aging WIP

The aging WIP report lists every item currently in flight and its age (days since started). Items older than the team's 85th-percentile cycle time are flagged as "at risk" -- they are statistical outliers and warrant explicit attention in standups and refinements.

Aging WIP is the single most actionable flow metric for daily use. Most teams ignore it. Most teams have a few items quietly aging in the corners.

Workflow

1. Export issue history from your tracker as JSON. Required fields per issue: id, title, created_at, status_history (list of {status, entered_at}), and ideally team and type. See references/flow-metrics-guide.md for tracker-specific export instructions.
2. Define your states. Tell the tool which status names map to "Ready" (commitment), "In Progress" (active work start), and "Done" (delivery). Defaults: Ready/To Do, In Progress, Done.
3. Run the analyzer. python scripts/flow_metrics.py --input issues.json --format markdown
4. Review the distribution. Look at 85th-percentile cycle time, not the average. Identify aging WIP that exceeds it.
5. Generate the CFD. Use --format mermaid to produce a cumulative flow diagram for share-back in retrospectives or exec reports.
6. Calibrate WIP limits. Use the WIP histogram to set per-state WIP limits at roughly the team's current 50th percentile.
7. Re-run weekly. Track the trend, not the snapshot. Flow metrics drift; only sustained changes are meaningful.

Tools

Demo mode: python scripts/flow_metrics.py --demo --format markdown produces sample output without input data.

Troubleshooting

Success Criteria

• All four flow metrics are computed and reported with both central tendency (median) and tail (85th percentile).
• The cumulative flow diagram is generated and shared in at least one retrospective per sprint.
• Aging WIP list is reviewed at least weekly; items exceeding 85th percentile cycle time get explicit attention.
• WIP limits are set per state based on observed flow rather than guessed.
• Trend reporting uses rolling windows (6-8 weeks), not single snapshots.
• Cycle time distribution is reported, never just an average.
• Flow metrics are used at the team level only; never for individual performance ranking.

Scope & Limitations

In Scope:

• Lead time, cycle time, throughput, WIP, aging WIP calculation
• Cumulative flow diagram generation (Mermaid)
• Per-type filtering (b