How to Use Historical Velocity for Better Sprint Planning
Most teams collect velocity data. Fewer use it well. Here's how to turn historical sprint data into reliable planning input rather than a number that gets ignored or gamed.
How much history you need
You need at least four sprints of data before velocity becomes a useful planning input. With fewer sprints, you're just averaging noise.
With four or more, you can start to see patterns: is velocity stable, trending up (as the team gels), or trending down (potential morale or process problem)?
Use a rolling average, not the last sprint
Last sprint's velocity is a single data point. It might be high because the team had no interruptions, or low because two people were sick. Use a rolling average of the last four sprints to smooth out variance.
Formula: (sum of last 4 sprints' velocity) ÷ 4
Build in capacity adjustments
Velocity is a baseline, not a ceiling. Adjust it for:
- Planned time off: reduce capacity proportionally
- Known interruptions: production incidents, interviews, on-call rotations
- New team members: expect 20-30% capacity reduction for the first 2-3 sprints
If average velocity is 40 and two developers are out for a week, plan for roughly 30.
What velocity can't predict
- The outcome of work that hits unexpected complexity mid-sprint
- The effect of context-switching between many small stories
- Whether the team's estimates are well-calibrated or systematically off
These require separate attention. Velocity is a capacity input, not a quality signal.
When velocity changes significantly
A velocity drop of more than 20% for two consecutive sprints usually points to something real: team change, increased scope of work, morale issues, or growing technical debt. Investigate before adjusting the number down and treating it as the new normal.
Historical velocity is your best available predictor of future capacity. Treat it as a signal, not a promise.