In the real world, people do change the end-date for Sprints. However, your question is really about whether you can extend a Sprint to complete unfinished work.
It's acceptable to plan a reduced-capacity Sprint to accommodate holidays or other business factors. It's not acceptable to treat Sprint boundaries as advisory.
The Sprint length should remain predictable. In the real world, it's occasionally necessary to make a Sprint shorter, move end-of-Sprint events up, or reduce the volume of work planned for the iteration. However, you should never extend a Sprint in order to accomplish more work.
Maintain a Predictable Cadence
A dynamic Sprint length is often a project smell. It's important that the time box for each Sprint is respected. Well-defined Sprint boundaries accomplish a number of things:
- They provides a predictable cadence for the project.
- Hard boundaries encourage smaller batch sizes.
- They regulate the work queue.
- Firm boundaries increase transparency.
- Predictability often increases stakeholder confidence and engagement.
Remember that moving the Sprint Review doesn't just affect the Development Team. If affects the stakeholders too, and often impacts multiple events besides the Sprint Review such as:
- Backlog Refinement
- the Sprint Retrospective
- the subsequent Sprint Planning
While you can move the boundaries to accommodate significant events such as holidays, there's a cost to doing so. You need to make that cost visbile to the project, and to the organization.
Adjust Cadence for the Right Reasons
Adjusting a Sprint's length can make sense if you're accommodating a major holiday, or if you have a significant capacity or scheduling problem. However, this has costs, which should be made extremely visible and paid as early as possible.
Reducing the capacity for the current Sprint meets that criteria, while extending the Sprint creates knock-on effects and pushes project debt into subsequent time boxes. Perhaps most importantly, extending a Sprint reduces visibility by hiding capacity, process, or estimation issues behind a utilization fallacy.
I've mentioned this before:
Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.
When you extend a Sprint to do more work, you're preventing the team from facing up to (potentially systematic) errors in planning, estimation, goal-setting, backlog coherence, dependency management, story decomposition, and other related issues. This loss of visibility and transparency creates project debt that becomes evermore burdensome every time you do it.
What to Do Instead
First, determine whether or not your Sprint Goal is at risk. Rather than extending your Sprint, talk with the Product Owner to determine whether the Sprint Goal can still be met if the work item remains undone or is re-scoped to fit within the current time box.
If the Sprint Goal can't be met, then the Product Owner should call for an early termination. The team should then hold a retrospective, immediately followed by a return to Sprint Planning.
Remember that a Sprint can succeed without 100% of planned work being done, and it can also fail even if every planned backlog item is completed. It's the Sprint Goal that matters, and if the Sprint Goal can't be met within the time box then the cost should be paid immediately and very visibly, rather than hidden by "framework adjustments."
Scrum Events: Cancelling a Sprint