Sprint Volatility
Measure how stable your sprint scope is — detect scope creep and planning accuracy problems before they compound.
Overview
Sprint Volatility measures how much a sprint's scope changes after it starts. High volatility means: issues are frequently added mid-sprint (scope creep), issues are pulled out (descoping), or both. This makes planning unreliable and velocity metrics meaningless.
Koalr tracks volatility across all completed sprints to show whether your planning process is improving or deteriorating.
What is measured
Scope change rate
Scope change rate = |added_points + removed_points| / planned_points × 100Where:
planned_points= story points at sprint startadded_points= points added after sprint startremoved_points= points removed after sprint start (descoped or moved out)
| Rate | Interpretation |
|---|---|
| < 10% | Stable — planning is reliable |
| 10–25% | Some churn — normal for evolving teams |
| 25–50% | High volatility — planning needs improvement |
| > 50% | Unstable — sprint scope is not meaningful |
Planning accuracy
Planning accuracy = min(completed_points, planned_points) / planned_points × 100This measures whether the team can predict what they'll complete. Teams with high planning accuracy have reliable velocity that can be used for forecasting.
Velocity consistency
Standard deviation of completed points across the past 6 sprints. High standard deviation = inconsistent output. Consistent output enables predictable delivery.
Dashboard sections
Sprint volatility summary
- Average scope change rate across the last 6 sprints
- Planning accuracy (% of sprint completed as planned)
- Velocity consistency (standard deviation of completed points)
- Risk level — LOW / MEDIUM / HIGH based on composite score
Volatility trend chart
Bar chart of scope change rate per sprint (last 8 sprints). Annotated with the source of volatility:
- Add-heavy sprints — new work was pulled in (reactive planning)
- Remove-heavy sprints — scope was descoped (over-committing)
- Mixed — both additions and removals
Sprint-by-sprint breakdown table
| Sprint | Planned pts | Added | Removed | Completed | Completion % | Scope change % |
|---|
Mid-sprint addition analysis
The most actionable view: what kinds of issues are being added mid-sprint?
Koalr categorizes mid-sprint additions by issue type:
- Bug — reactive bug fixes displacing planned work
- Feature — new scope from product/stakeholders
- Incident-related — work arising from production incidents
- Unplanned dependency — blocked work on other team causing mid-sprint swaps
Understanding the composition helps you address the root cause (e.g., better triage process for bugs vs. clearer sprint commitment conversations with product).
Team comparison
Per-team volatility for orgs with multiple teams. Platform/infrastructure teams typically have higher volatility than product teams due to reactive incident work.
Reducing sprint volatility
- Definition of Ready — only pull issues into a sprint that have acceptance criteria, estimates, and design finalized
- Sprint firewall — designate a buffer (~20% capacity) for reactive work; don't promise 100% of capacity to planned sprint goals
- Separate bug triage — run a parallel bug queue outside the sprint so bugs don't displace planned work
- Stakeholder alignment — establish a "no new scope after day 2" norm with product and leadership
- Smaller sprint commitment — consistently completing 90% of a smaller commitment is better than completing 60% of an overloaded sprint
Relationship to other metrics
- Sprint Burndown — volatility explains why burndowns go flat or spike unexpectedly (Sprint Burndown)
- Forecasting — high volatility makes delivery forecasting less accurate (Forecasting)
- Incidents — incident-driven volatility correlates with reliability metrics (Incidents)
- Context Switching — mid-sprint reactive work is a major driver of context switching (Context Switching)