Year-End Sprint Planning: How to Estimate Around Holidays

The last two sprints of the year are the most consistently misplanned sprints on most teams' calendars. People are out. Focus is low. Deployments get frozen. Yet teams often plan these sprints at full capacity.

The capacity reality

A two-week sprint where three of six developers are on leave for at least a week is not a normal sprint. Calculate actual available days and use that to set sprint capacity, not the usual velocity.

A simple formula: (normal team days per sprint) × (available fraction). If your team normally has 60 developer-days per sprint and you're losing 30% to leave, plan for 42 developer-days.

What kinds of work to prioritize

Good work for holiday sprints:

• Low-risk improvements and minor bug fixes
• Documentation and test coverage work
• Technical debt that doesn't touch production-critical paths
• Stories that a single developer can own end-to-end without needing review

Avoid in holiday sprints:

• Complex features with cross-team dependencies
• Infrastructure changes that require monitoring during rollout
• Stories that block the rest of the team

The deployment freeze issue

Many companies freeze production deployments in late December. If your stories require deployment, they can't be "done" in the traditional sense during a freeze. Either adjust your Definition of Done for the sprint, or fill the sprint with work that can be merged but not deployed.

Setting the right expectation

Tell stakeholders at the start of Q4 that December sprints will have reduced velocity. Build this into any Q4 commitment you make in October. Surprises in December damage trust; forecasts protect it.

Reliable delivery during the holidays looks like modest commitments met, not ambitious targets missed.