ES-05
Complexity Chart Anomaly
Estimation
Default severity: medium
EstimationMetricsQualityEffort
What it detects
Max time within a story point size class exceeds the min by more than the configured factor — the point size is not calibrated to actual effort.
Detection formula
IF (max_time\[sp_class\] / min_time\[sp_class\]) > config.estimation.complexity_spread_factor // default: 20x THEN FLAG for that sp_class Report per sp_class: min, max, median, spread_ratioExamples in practice
- Estimates, time logged, and actual effort no longer align for a meaningful share of items.
- The team commits to sizes that are not supported by historical spend patterns.
- A team shows max time within a story point size class exceeds the min by more than the configured factor while complexity spread factor is set to 20x.
Suggested response
Align estimation and logging practices so size, time spent, and scope changes remain comparable.
Coaching playbook
Symptom
Max time within a story point size class exceeds the min by more than the configured factor — the point size is not calibrated to actual effort.
Why it matters
When "Complexity Chart Anomaly" 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
Align estimation and logging practices so size, time spent, and scope changes remain comparable.
Facilitation questions
- What system change would stop "Complexity Chart Anomaly" 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.