SC-02
Sprint Scope Removal — Issues Removed Mid-Sprint
Scope Control
Default severity: medium
PrioritizationProcessRiskEffort
What it detects
Issues were removed from an active sprint after the scope lock point without being completed — scope was dropped, not delivered. Measured across all four dimensions. Distinguishes between completed removals (done, moved) and silent drops (moved back to backlog without completion). scope_lock = sprint.start_date + config.sc.sprint_scope_lock_hours removed = changelog.filter(field=\'sprint\', old=sprint.id, date > scope_lock)
Detection formula
FOR each_removed_issue I: IF I.status NOT IN config.workflow.done_statuses THEN silent_drop = true IF silent_drop: dropped_sp += I.story_points dropped_hours += I.original_estimate dropped_bv += I.bv dropped_count += 1 IF dropped_sp / committed_sp > config.sc.drop_sp_threshold // default: 5% THEN FLAG IF dropped_count > 0 AND no_flag_was_raised THEN WARN (undisclosed drops — governance issue)Examples in practice
- A team shows issues were removed from an active sprint after the scope lock point without being completed while done statuses is set to Configured per workspace.
- Example signal: Issues were removed from an active sprint after the scope lock point without being completed — scope was dropped, not delivered.
Suggested response
Gate sprint and PI scope changes with visible rationale and stable commitments.
Coaching playbook
Symptom
Issues were removed from an active sprint after the scope lock point without being completed — scope was dropped, not delivered. Measured across all four dimensions. Distinguishes between completed removals (done, moved) and silent drops (moved back to backlog without completion). scope_lock = sprint.start_date + config.sc.sprint_scope_lock_hours removed = changelog.filter(field=\'sprint\', old=sprint.id, date > scope_lock)
Why it matters
When "Sprint Scope Removal — Issues Removed Mid-Sprint" 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 Removal — Issues Removed Mid-Sprint" 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.