The Sprint is a fixed length event of one month or less, and every other event happens inside it. A new Sprint begins immediately after the previous one concludes, which is what gives Scrum its cadence. There is no gap for stabilisation and no pause to prepare the next one.
The container for the other four events
Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective all take place inside a Sprint. Calling the Sprint their container matters because the Sprint is the unit that has to produce something of value, and the four events within it are the inspection and adaptation points that make that likely.
Two things follow. No event inside a Sprint can be dropped for time, so a team that skips the Retrospective when things are busy has removed the only scheduled point at which the way it works can change. And each Sprint can be considered a short project, with a goal, a plan, a delivery and a review all happening inside it.
What is fixed and what is not
The length of a Sprint is fixed, and so is the quality of what comes out of it, because the Definition of Done sets a standard that does not move to make a deadline reachable. Scope is the part that flexes. As the Developers learn what the work actually involves, they and the Product Owner may clarify and renegotiate it, so long as the Sprint Goal itself is not put at risk.
That combination is the whole bargain of a Sprint. You get a fixed date and a fixed standard, and in exchange the amount of work delivered is allowed to change as understanding improves.
What holds while a Sprint is running
Four things hold for the length of a Sprint, and they follow from the bargain above. No change may be made that would endanger the Sprint Goal, since the goal is the commitment the Sprint is being run to meet. Quality does not decrease, since lowering the Definition of Done would hide unfinished work rather than remove it. The Product Backlog is refined as needed throughout, because refinement is ongoing work rather than a scheduled event, and stopping it would leave the next Sprint Planning with nothing ready to select.
The fourth is that scope may be clarified and renegotiated with the Product Owner as more is learned. That is the release valve, and it belongs to the Developers and the Product Owner jointly rather than to either of them alone, because the renegotiation is a conversation about what still serves the Sprint Goal.
Why shorter Sprints cost less
A shorter Sprint generates more learning cycles and confines the cost of being wrong to a smaller window. Stretch the horizon too far and two things go wrong together. The Sprint Goal has longer to become invalid before anyone acts on it, and complexity accumulates faster than the team can inspect it.
The Sprint length is therefore the maximum amount of work that can turn out to rest on a wrong assumption. A team on one week Sprints can lose a week, while a team on one month Sprints loses a month and will have spent much of it building further work on the same assumption.
Shorter is not free, because every Sprint carries the fixed cost of its events and of getting something all the way to Done, so as the length falls that overhead becomes a larger share of the whole. The Guide fixes only the ceiling of one month and the requirement that the length stay consistent, and leaves the choice within that to the Scrum Team.
Cancellation
A Sprint may be cancelled when the Sprint Goal becomes obsolete, which usually means the world changed rather than that the team fell behind. Only the Product Owner has that authority. Cancellations are uncommon, because Sprints are short enough that finishing usually costs less than stopping.
The 2020 Guide says nothing about what follows a cancellation, which leaves the handling of incomplete work to the Scrum Team. In common practice the unfinished items return to the Product Backlog and a new Sprint begins with Sprint Planning.