Handling Velocity Seasonal Variations - Holidays & Vacation Planning
Our velocity tanks every December (holidays) and summer (vacations). How do you plan sprint capacity when you know team availability will fluctuate? Do you adjust story points or just accept lower velocity?
Calculate velocity per available person-day, not per sprint. This normalizes seasonal variations.
Normal sprint: 50pts delivered / 100 person-days available = 0.5 pts/day. Holiday sprint with 30% team off: 60 person-days available * 0.5 pts/day = 30pts capacity. Simple math, predictable planning year-round. Stakeholders see "30pts planned" not "we'll probably miss our commitment."
We run "light sprints" in December and August. Cut sprint length from 2 weeks to 1 week, plan only high-priority small stories (2-3 points max). No complex features, just bug fixes and tech debt.
Reduces pressure, team doesn't return from vacation to a disaster sprint. Product owner loves it because critical fixes still happen. Better than pretending we'll deliver normal velocity.
Track capacity factor per sprint. 100% = full team available, 70% = typical December, 80% = summer vacation season. Multiply historical average velocity by capacity factor.
December sprint: 50 avg velocity * 0.70 capacity = 35pts planned. Simple, accurate, stakeholders understand it. We publish capacity factor in sprint planning invite so everyone comes prepared.
Controversial: Don't adjust at all. Velocity is velocity - it measures what the team actually delivers. If team delivers 20pts instead of 50, that's reality, not a failure.
Adjusting estimates or capacity factors creates fake metrics. Instead, communicate early: "Team is 40% down next sprint due to vacation calendar." Stakeholders adjust expectations, not estimates. Velocity stays honest.