CT-01
Extreme Cycle Time Spread
Cycle Time
Default severity: medium
ProcessMetricsOutputRisk
What it detects
Min vs Max cycle time ratio exceeds the configured spread threshold — indicates mixed work types on a single board making forecasting statistically unreliable.
Detection formula
IF (max_cycle_time / min_cycle_time) > config.ct.spread_ratio_threshold // default: 100 IF stddev(cycle_times) > avg(cycle_times) * config.ct.stddev_avg_ratio // default: 0.8 THEN FLAGExamples in practice
- A board completes small tasks in hours and epics in 120+ days — the min/max cycle time ratio exceeds the spread threshold.
- Cycle time standard deviation runs above 80% of the average, signalling incompatible work types on one board.
- Delivery forecasts based on a single team average become unreliable when variance is driven by mixed work streams.
Suggested response
Review cycle-time drivers on the cited work items; tighten WIP or handoffs where delays repeat.
Coaching playbook
Symptom
Min vs Max cycle time ratio exceeds the configured spread threshold — indicates mixed work types on a single board making forecasting statistically unreliable.
Why it matters
When "Extreme Cycle Time Spread" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.
What you can achieve
Review cycle-time drivers on the cited work items; tighten WIP or handoffs where delays repeat.
Facilitation questions
- What system change would stop "Extreme Cycle Time Spread" from firing again?
- What do the cited issues have in common — same root cause or same workaround?
- Who owns the two-week experiment and how will we verify on the next import?
Run this rule against your own tracker data with Flow Analyzer.