• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Sprint Volatility Index (Scope Change During Sprint)

Description

Sprint Volatility Index measures the percentage of work that changes (added, removed, or re-scoped) during a sprint relative to what was initially planned. It reflects the stability of the sprint backlog and the team’s ability to maintain focus and honour commitments.

This metric helps teams and stakeholders recognise when delivery is being disrupted by scope churn, shifting priorities or reactive decision-making. High volatility undermines predictability, planning reliability, and stakeholder confidence.

How to Use

What to Measure

  • Capture the initial sprint scope (in story points or item count).
  • Track all changes during the sprint:
    • New work added
    • Work removed or de-scoped
    • Significant rework or replaced items
  • Calculate volatility as the total changed scope relative to the original commitment.

Formula

Sprint Volatility Index (%) = (Scope Changed During Sprint / Scope Committed at Start) × 100

Examples:

  • 20 story points planned, 6 points added, 2 removed → 8 changed = 40% volatility
  • 10 items committed, 3 added, 1 removed → 4 changed = 40% volatility

You may also report:

  • Directional volatility (added vs removed work)
  • Root causes of change (urgent demand, poor planning, dependency failure)

Instrumentation Tips

  • Tag added/removed items in the sprint backlog.
  • Use audit logs or delivery tool filters to detect scope changes over time.
  • Align scope definitions to a consistent unit (e.g. stories, points, or both).

Benchmarks

Target levels vary based on team maturity and domain:

Volatility (%) Interpretation
<10% Stable and focused sprint execution
10–25% Moderate scope churn, requires monitoring
>25% High volatility, likely undermining delivery confidence

Look for consistency and improvement over time, not just one-off events.

Why It Matters

  • Improves delivery stability
    Low volatility sprints are easier to plan, execute, and forecast.

  • Supports team morale and flow
    Teams experience less thrash and context switching when scope is stable.

  • Builds stakeholder confidence
    Reduces the risk of last-minute surprises and unplanned trade-offs.

  • Reveals upstream issues
    Frequent in-sprint changes may reflect problems in prioritisation, refinement, or business readiness.

Best Practices

  • Finalise sprint scope collaboratively and make it visible at planning.
  • Introduce structured policies for handling in-sprint changes (e.g. “1 in, 1 out”).
  • Engage stakeholders early to avoid last-minute surprises.
  • Review volatility metrics in retrospectives to identify patterns and root causes.
  • Maintain a clear audit trail of scope changes.

Common Pitfalls

  • Treating the sprint backlog as fully fluid, undermining the purpose of the sprint.
  • Failing to distinguish between necessary adaptations and reactive churn.
  • Overcommitting at planning time, leading to predictable mid-sprint scope cuts.
  • Ignoring directional volatility (adding more than removing, or vice versa).

Signals of Success

  • Sprint volatility is low and trending downward over time.
  • Changes that do occur are deliberate, reasoned, and transparent.
  • Teams report higher focus, less mid-sprint disruption, and improved throughput.
  • Product and business stakeholders trust sprint outcomes and cadence.

Related Measures

  • [[Work Replanning Rate]]
  • [[Planned vs. Completed Work Ratio]]
  • [[Delivery Commitment Confidence Score]]
  • [[Flow Stability (Variance in Cycle Time or Throughput)]]

Aligned Industry Research

  • Scrum Guide
    Emphasises the importance of a stable sprint backlog that supports goal delivery without unnecessary disruption.

  • Agile Estimating and Planning (Mike Cohn)
    Advocates for avoiding mid-iteration changes to maintain planning integrity and reduce waste.

  • Evidence-Based Management (Scrum.org)
    Suggests monitoring change volatility to improve process control and long-term predictability.

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering