Moving the sprint end date

Most of Canada has May 24th off work – Quebec calls it “National Patriotes Day” but everyone else knows it as Victoria Day. But what do you do if it falls during your sprint? I’ve heard some teams move the sprint end date to compensate, so their sprint is still the same number of working days. (I’ll use 2-week sprints for simplicity but YMMV – I’ve worked with teams using 1-week, 3-week or 4-week sprints, but I’ve never seen a non-integer week duration; have you?)

I can understand the thinking behind moving the sprint end date because that gives them the same capacity as other sprints, but I think it’s a slippery slope: would you move the sprint end if some of the team are on vacation for a week? What if the company introduces a weekly all-hands meeting that consumes 90 minutes of everyone’s time? Do you move the sprint review and retrospective by the same amount?

The intent behind setting a regular cadence for your scrum events is so that everyone knows when they happen, and it simplifies meeting scheduling (set a recurring appointment and let it run). Often key stakeholders have busy schedules, so knowing the sprint review will always happen at the same time makes it easier for them to move meetings around it. (I would argue that your stakeholders’ willingness to prioritise your sprint review over other activities is a reflection of the value/importance of the work you’re doing.)

A regular cadence does not mean that your sprints will always have the same capacity – today’s stat day (aka Bank Holiday in the UK) means a reduction of 10% of the sprint… or more if some of the team took Friday off to make a 4-day weekend. Hopefully, the team thought about this when they planned the sprint and adjusted accordingly. Some teams I’ve worked with use a simple spreadsheet as a reminder to check each team members’ availability – maybe one person is on vacation for a week and another is on a course for 3 days.
I stop short of then calculating what percentage of the team is available and applying that to their velocity – this isn’t a precise science, just an aide-memoire to get them to think before they plan. If the team still relies on one person for a particular skill (e.g. database design) and they’re away then maybe the team needs to rethink which stories they can complete… and hopefully that’s also the trigger for them to work out how to share that skill so they don’t hit the same problem again.

An extreme case usually happens around the end of the year: a combination of holidays, stat days, and using up personal vacation time can mean a 2-week sprint has a tiny fraction of the normal capacity. I’ve seen teams make an exception and have a one-off extended sprint, spanning three or maybe even four weeks. I’ve seen teams just stick to their cadence and plan on completing far fewer stories. Recently I saw some teams try an interesting experiment where they abandoned sprints and teams for those weeks – instead, they took the opportunity to work on their tech debt backlog and pair/mob with people they don’t usually work with. There’s no “right” way to handle the unusual circumstances but I would recommend resuming the regular cadence as soon as possible.