SP-03
Scope Creep
Sprint / Planning
Default severity: high
PrioritizationEstimationOutputEffort
What it detects
Story points added to a sprint after the configured grace period from sprint start exceed the configured percentage of the original sprint commitment. grace_end = sprint.start_date + config.sprint.scope_lock_days // default: 1d after start sp_added_after_lock = SUM(sp WHERE sprint_add_date > grace_end)
Detection formula
IF sp_added_after_lock / sprint_committed_sp > config.sprint.scope_creep_threshold // default: 10% THEN FLAGExamples in practice
- Sprint commitments, velocity, or late scope changes tell conflicting planning stories.
- Committed scope shifts materially after the sprint lock point.
- A team shows story points added to a sprint after the configured grace period from sprint start exceed the configured percentage of the original sprint commitment while scope creep threshold is set to 10%.
Suggested response
Reconcile sprint commitments, velocity signals, and late scope changes with the team.
Coaching playbook
Symptom
Story points added to a sprint after the configured grace period from sprint start exceed the configured percentage of the original sprint commitment. grace_end = sprint.start_date + config.sprint.scope_lock_days // default: 1d after start sp_added_after_lock = SUM(sp WHERE sprint_add_date > grace_end)
Why it matters
When "Scope Creep" 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
Reconcile sprint commitments, velocity signals, and late scope changes with the team.
Facilitation questions
- What system change would stop "Scope Creep" 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.