Our next sprint starts on Dec 18th and should end on Jan 1st. Most of the team will be unavailable on Christmas and boxing day. The PO will also miss about 4 days of that sprint.
The problem is Jan 1st is a public holiday and I do not want to change the scheduling of the ceremonies as I see the team getting into routine. Also, the next couple of days of the week of Jan 1st in my opinion feels like a low efficiency period for the team.
How do I go about this?
When a scrum activity falls on a business holiday, I move it either earlier or later. I try to put it as close to the scheduled day as possible, but sometimes need to be more flexible if there are participants external to the team, like for the sprint review, who may also be taking time off around the holidays.
At least in the USA, everyone understands that the last half of December and the first few days of January are unpredictable because so many people take time off. No one expects the last half of December to work the same as the last half of any other month.
So I would lean on that: "oh, everyone's schedules are unpredictable at this time of year, so we're adjusting..." It may be frustrating, because you're seeing the team just start to get into a routine, but I suspect that practical compromise around "the holidays" and returning to the regular routine thereafter will get better results in the long run.
Good luck!
You have two options:
I would suggest the second option. Especially since you say the team is getting into the routine. Also, the Scrum Guide says that
Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
The holidays are not different than when people are sick for example, and take days off, or have PTO days (although not many at once, usually). What do you do then? You most likely plan a sprint like any other but taking less work in that iteration to account for the reduced team capacity.
So this isn't any different, just bigger in size. So plan a sprint for the known capacity. Prepare with the team something achievable by the people still working, make that the sprint goal, then run with it.
With that said, the team should decide. Keep the suggestion (you should remember and try to stick to the core ideas of Scrum), but also listen to the team. The team should be self-organizing, and that also means how they would do the work given the holiday season.
Our next sprint starts on Dec 18th and should end on Jan 1st. Most of the team will be unavailable on Christmas and boxing day. The PO will also miss about 4 days of that sprint.
While predictability in Scrum ceremonies is important to maintaining an effective cadence, it should not be a straitjacket. Pragmatically speaking, it's generally better to make a Sprint slightly shorter than it is to make it longer since the Sprint length should represent the outer bounds of the time box. With that in mind, you should probably plan to end your Sprint on Friday, Dec. 29th, 2023.
If you decide to extend rather than shorten your Sprint to ensure higher participation over the holidays, you can do that too. I just don't recommend it. Still, if you go that route, then you can end your Sprint on Tuesday, January 2nd, 2024 using a slightly shorter format to reflect the reduced capacity for the Sprint, and then go right into your Sprint Retrospective and Sprint Planning. This compresses the schedules for the Sprint Review, Sprint Retrospective, and (possibly) Sprint Planning rather than reducing capacity, but unless you routinely end your Sprints on a Monday (which is likely to lead to a separate Q&A) it only shifts your cadence by one day as a one-time modification.
Either way is an acceptable trade-off. Just make sure you understand the trade-offs, and favor whichever one is likely to lead to the highest level of participation. In my own experience, compressing one Sprint and accepting a one-day reduction in capacity for the following Sprint is a better choice than extending the time box during a period of reduced capacity, and then having to compress the next Sprint by roughly two days instead of one. Your mileage (and people's holiday vacation plans) will certainly vary.
Also, the next couple of days of the week of Jan 1st in my opinion feels like a low efficiency period for the team.
The weeks just before the holidays, as well as the week after, are both likely to result in reduced-capacity Sprints. That's normal. The goal of Scrum is to provide transparency, visibility, and predictability. Reduced capacity around holidays is pretty much the definition of "predictable," so don't fall prey to the utilization fallacy here.
The best way I know of to address this is to have the team apply a reasonable fudge factor to their Sprint Planning during the holiday period. As a rough example, let's say that you use story points and that your team typically does 15-20 story points per Sprint. Assuming the Scrum Team as a whole will miss about 50% of the last and first Sprints of the year, the team should apply as many of the following techniques as it can.
Apply a fudge factor of 0.5 to the team's typical velocity of 15-20 points, cutting the expected capacity of the affected Sprints to 7-10 story points each.
Note: If you have multiple Sprints that will be affected, you can use different fudge factors for planning each one, or just average them out. Since your real objective should be to meet the Sprint Goal, not necessarily to complete a fixed number of story points, this technique helps with capacity planning but is secondary to selection of the right Sprint Goal as discussed below.
Use "fist to five" or some other confidence rating to determine if the team has at least 80% confidence that the current Sprint Goal can still be met even with reduced capacity or less-active collaboration.
Ensure that the stories support a single Sprint Goal that is still meaningful, but perhaps represent a smaller step towards the current Product Goal than the team might otherwise define for themselves.
Remember that you don't have to wait until the end of a Sprint to deliver or release an Increment.
Note: This might be a good time to think about continuous delivery, continuous deployment, and feature toggles. The Sprint Review is really an opportunity to "inspect the outcome of the Sprint and determine future adaptations" (Schwaber & Sutherland, 2020) rather than a meeting to demo or release new features, so making this switch might solve for both scheduling and capacity planning issues, as well as any potential misuse of the Sprint Review event itself.
Communicate ahead of time! Have the Product Owner and the rest of the Scrum team collaborate with external stakeholders such as clients, end users, or other Sprint Review attendees to proactively set their expectations a little lower due to the holidays.
By aligning everyone's expectations, and ensuring that the Scrum Team isn't over-committing during a period of reduced capacity, you should still be able to provide one or more usable Increments without setting the team up for failure. And remember, even if the team somehow misses even the reduced Sprint Goal, that's just another opportunity to inspect-and-adapt your estimation process during your next Sprint Retrospective. After all, while the end of the year is often the most common time for this sort of issue to come up, it will come up at other times, and having a team-defined process for handling reduced capacity, scheduled events disrupted by holidays, or other eventualities is part of the continuous improvement process at the heart of any framework that applies agile values and principles.
