SC-01
Sprint Scope Injection — Issues Added After Lock
Scope Control
Default severity: medium
PrioritizationProcessRiskEffort
What it detects
Issues were added to an active sprint after the configured scope lock point (default: 24h after sprint start). Measured across all dimensions: how many issues, how many SP, how many hours of estimated work, and how much BV was injected mid-sprint. Each injection event is a separate finding. scope_lock = sprint.start_date + config.sc.sprint_scope_lock_hours // default: 24h injected = changelog.filter(field=\'sprint\', new=sprint.id, date > scope_lock)
Detection formula
FOR each_injection_event: injected_issues = COUNT(injected) injected_sp = SUM(story_points, injected_issues) injected_hours = SUM(original_estimate, injected_issues) injected_bv = SUM(bv, injected_issues) IF bv_field configured IF injected_sp / committed_sp > config.sc.injection_sp_threshold // default: 5% THEN FLAG IF injected_sp / committed_sp > config.sc.critical_injection_pct // default: 15% THEN CRITICALExamples in practice
- A team shows issues were added to an active sprint after the configured scope lock point (default: 24h after sprint start) while injection sp threshold is set to 5%.
- Example signal: Issues were added to an active sprint after the configured scope lock point (default: 24h after sprint start).
Suggested response
Gate sprint and PI scope changes with visible rationale and stable commitments.
Coaching playbook
Symptom
Issues were added to an active sprint after the configured scope lock point (default: 24h after sprint start). Measured across all dimensions: how many issues, how many SP, how many hours of estimated work, and how much BV was injected mid-sprint. Each injection event is a separate finding. scope_lock = sprint.start_date + config.sc.sprint_scope_lock_hours // default: 24h injected = changelog.filter(field=\'sprint\', new=sprint.id, date > scope_lock)
Why it matters
When "Sprint Scope Injection — Issues Added After Lock" 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
Gate sprint and PI scope changes with visible rationale and stable commitments.
Facilitation questions
- What system change would stop "Sprint Scope Injection — Issues Added After Lock" 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.