SC-06
Sprint Scope Change Frequency Trend
Scope Control
Default severity: medium
PrioritizationProcessRiskEffort
What it detects
The number of scope change events per sprint is increasing over consecutive sprints — sprint instability is worsening, not improving. Trend analysis across issues count, SP, and BV dimensions.
Detection formula
FOR each_sprint S in last N sprints (N = config.sc.trend_sprint_count, default 6): churn(S) = total_churn_sp(S) / committed_sp(S) IF linear_regression(churn_series).slope > 0 AND r_squared > config.sc.trend_r_squared // default: 0.6 THEN FLAG increasing_instability If trend is sustained: predictability is actively deteriorating Report: churn rate per sprint as time seriesExamples in practice
- A team shows the number of scope change events per sprint is increasing over consecutive sprints while trend sprint count is set to Configured per workspace.
- Example signal: The number of scope change events per sprint is increasing over consecutive sprints — sprint instability is worsening, not improving.
Suggested response
Gate sprint and PI scope changes with visible rationale and stable commitments.
Coaching playbook
Symptom
The number of scope change events per sprint is increasing over consecutive sprints — sprint instability is worsening, not improving. Trend analysis across issues count, SP, and BV dimensions.
Why it matters
When "Sprint Scope Change Frequency Trend" 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 Change Frequency Trend" 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.