BC-03
Sprint Burn-Down — Late Spike at Sprint End
Burn Charts
Default severity: medium
PrioritizationMetricsOutputEffort
What it detects
A disproportionate share of remaining work is completed in the final day or two of the sprint across any dimension — indicates batch delivery, not continuous flow. The burn-down was flat then dropped sharply at sprint boundary.
Detection formula
FOR each_dimension D: last_2d_completion = delta(remaining(D), sprint.end - 2d, sprint.end) total_completion = delta(remaining(D), sprint.start, sprint.end) IF last_2d_completion / total_completion > config.bc.end_spike_threshold // default: 0.4 THEN FLAG — late spike pattern Correlate with FL-02 (sprint-end bulk transitions) and MI-04 (sequential sweeps)Examples in practice
- A team shows a disproportionate share of remaining work is completed in the final day or two of the sprint across any dimension while end spike threshold is set to 0.4.
- Example signal: A disproportionate share of remaining work is completed in the final day or two of the sprint across any dimension — indicates batch delivery, not continuous flow.
Suggested response
Re-plan remaining scope when burn charts show late work, scope creep, or stalls.
Coaching playbook
Symptom
A disproportionate share of remaining work is completed in the final day or two of the sprint across any dimension — indicates batch delivery, not continuous flow. The burn-down was flat then dropped sharply at sprint boundary.
Why it matters
When "Sprint Burn-Down — Late Spike at Sprint End" 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
Re-plan remaining scope when burn charts show late work, scope creep, or stalls.
Facilitation questions
- What system change would stop "Sprint Burn-Down — Late Spike at Sprint End" 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.