ES-02
Severe Time Overrun
Estimation
Default severity: critical
EstimationMetricsQualityRiskEffort
What it detects
Actual time spent exceeds original estimate by a factor above the configured overrun multiplier across more than the configured percentage of issues.
Detection formula
IF COUNT(issues WHERE spent/estimate > config.estimation.overrun_multiplier) / total // default: 5x > config.estimation.overrun_population_pct // default: 20% THEN FLAGExamples 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 actual time spent exceeds original estimate by a factor above the configured overrun multiplier across more than the configured percentage of issues while overrun multiplier is set to 5x > config.estimation.overrun_population_pct.
Suggested response
Align estimation and logging practices so size, time spent, and scope changes remain comparable.
Coaching playbook
Symptom
Actual time spent exceeds original estimate by a factor above the configured overrun multiplier across more than the configured percentage of issues.
Why it matters
When "Severe Time Overrun" 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 "Severe Time Overrun" 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.