Handling Velocity Volatility
Our velocity swings from 15 to 45 points sprint-to-sprint. Makes forecasting impossible. What causes this and how do you stabilize it?
High volatility signals process problems, not estimation problems. Common causes: (1) Scope creep mid-sprint - track unplanned work separately. (2) Inconsistent story sizes - enforce "13 points max, split bigger". (3) Team size fluctuations - normalize velocity per person. (4) Definition of Done inconsistency - document DoD, enforce strictly.
Fix the process first, velocity will stabilize naturally.
Use velocity range instead of single number. Track min/max/median over 6 sprints. Report: "We deliver 20-35 points per sprint, median 28." Sets realistic expectations. Trying to hit exact number with volatile data is futile.
Investigate outlier sprints. When velocity spikes or crashes, do immediate mini-retro: why? Usually finds systemic issues. We discovered half our volatility was "demo week" where devs prep presentations instead of coding. Now we budget for it.
Cap work in progress strictly. Our volatility came from starting too many stories, finishing few. Now: max 2 stories in progress per dev. Velocity stabilized within 3 sprints. Limit WIP = limit variance.