This question is posed as a genuine attempt to seek a best answer but also hopefully a wider-thought piece.

How do more experienced agile teams (especially Scrum) handle a sprint being interrupted by the holiday season (or Generic.Event) which greatly disrupts the standard workflow.

To focus this question further I will use the most pressing concerns that our team faced over the Christmas period

  • Product Owner was absent (mid-Dec to early Jan) over 60% of the Sprint including the planned Review
  • Deputized Product Owner was the same
  • Senior Management were likewise
  • 50% of the development team took mandated holidays for 50% of the Sprint
  • 50% of the development team wished to keep working and only had Xmas Day and Boxing Day off
  • The timebox was scheduled to end on Xmas Eve as all of our Sprints end on the 24th of the month
  • Critical members of the team were unavailable until early January to plan or estimate stories

I know how we handled this situation but it would be great to crowdsource an optimal solution from SMs or POs or Project Managers who have faced this problem numerous times across various organisations.

3 Answers 3


Apply a Fudge Factor

The proper way to deal with reduced team capacity is to apply a fudge factor to the team's planned story points for the Sprint. The size of the time box doesn't change, but the planned capacity for the time box should. Since the Development Team is responsible for accepting only the stories it expects to be able to complete into each Sprint, the team should use velocity as an input to estimating capacity rather than using it as a fixed management target.

The team is in the best position to estimate the reduction in its capacity; there's no fixed formula that will work in all situations. However, as is common in project management, the limiting factor is often your largest resource constraint: if the Product Owner will be unavailable for 60% of the Sprint, it is unlikely that the team can do more than 40% of its typical velocity, and perhaps even less if the holiday absences don't overlap.

For example, suppose your team averages 20 story points per Sprint. For the holiday Sprint, the team estimates that its capacity will be reduced by 75%. The team should therefore only accept 5 story points into the Sprint during Sprint Planning.

Recalculate Each Sprint

If you have more than one Sprint over your holiday period, then you should re-estimate and re-apply the fudge factor to your rolling velocity calculations each Sprint. The impact in your long-term velocity metrics is generally negligible, but the accuracy of your short-term estimates often improve by acknowledging the V-shaped changes in the team's capacity over the relevant time period.

Don't Discard the Metric

If you properly include the reduced-capacity Sprint in your trailing-average or annualized velocity metrics, you will end up with a much more accurate view of your project's real capacity over time. It may be tempting to exclude the holiday Sprint from your velocity calculations as a one-off, but discarding historical data is likely to skew your long-term estimates, and there will of course be other holidays or capacity issues in the future.

The point of velocity is that it reflects a sustainable average over time. Team capacity fluctuates, but if you keep the focus on the sustainable center of your bell curve then the majority of your Sprints will be a success.

  • I completely disagree that the timebox doesn't need to change. If the PO isn't available for the review, then the timebox needs to change to accommodate this.
    – David Arno
    Commented Jan 8, 2015 at 11:06

Quick Answer:

  • Create a team calendar (confluence/sharepoint/anywhere accessible to the entire team
  • Before sprint/release planning, have the team and stakeholders update - review this calendar at the start of sprint planning to make sure everyone is on the same page with commitments.
  • Towards the end of sprint planning, review how much work each team member has committed to and question whether it is feasible with the vacation calendar visible. E.g my DBA may commit to deploying changes but may not be cognizant that tester 1 is out for x days and tester 2 is out for y.

This helps the team better manage commitments during vacation heavy times of the year, it also helps set and adjust product owner expectations during that same time period.

Sorry for grammar/typos I am on mobile


The simple answer is to be be flexible, ie be agile: adjust things to cope with the events. If the Product Owner is known to be away for a planned review, then don't plan the review for that date. Just because it has always happened on that date doesn't mean it always has to.

Your problem is that you always have sprints finishing on a fixed day. In this case, it would have been better to eg have run a shorter sprint that ended a week earlier and then have planned around known absences over Christmas for the following sprint. Either than could have been a longer sprint *(finishing 24th January) or you could have had two more shorter sprints that ended early January and then on the 24th.

The moral of the story is: agile development is all about being flexible and responding to events, rather than rigidly sticking to long term plans and schedules.

  • Hi David, I did implement an Agile solution (longer sprint followed by shorted with rescheduled ceremonies) - I just used our constraints as an example. Commented Jan 5, 2015 at 12:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.