The Sprint is a fixed length event of one month or less, and every other event in Scrum happens inside it. The Guide calls Sprints the heartbeat of Scrum, because a Sprint is where ideas turn into value and the next one begins the moment the last one ends. That leaves no gap for stabilisation and no pause to prepare the next one, so the cadence a team sets is the cadence it keeps.
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, while the four events inside it are the inspection and adaptation points that make a valuable outcome likely.
Two things follow from that. The first is that no event inside a Sprint can be dropped for time, so a team that skips the Retrospective whenever a release is close has removed the only scheduled point at which the way it works can change. The second is the Guide's own observation that each Sprint may be considered a short project, since a goal, a plan, a delivery and a review all sit inside it.
What a Sprint fixes and what it allows to change
Two things about a Sprint do not move. The length is fixed, and so is the quality of what comes out of it, because the Definition of Done sets a standard that does not drop 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 nothing they agree endangers the Sprint Goal.
That combination is the whole bargain of a Sprint. The team works to a fixed date and a fixed standard, and in exchange the amount of work it delivers is allowed to change as understanding improves. A team halfway through a migration off a legacy billing service can drop two reports from the Sprint and still meet its Sprint Goal. The goal was to move the first customer segment onto the new service, and the reports were only part of the plan for getting there.
What holds while a Sprint is running
Four conditions hold for the length of a Sprint, and each of them follows from that bargain. Nobody makes a change 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 only hides the unfinished work and leaves all of it still to do. The Product Backlog is refined as needed throughout, because refinement is continuous work with no event of its own, so letting it lapse would leave the next Sprint Planning with nothing ready to select.
The fourth condition is the release valve the other three need. Scope may be clarified and renegotiated with the Product Owner as more is learned, and that renegotiation belongs to the Developers and the Product Owner together, because the question it settles is what still serves the Sprint Goal.
What the Scrum Master protects during a Sprint
None of those four conditions enforces itself, and the Scrum Master is the person the Guide places closest to them. The accountability is for establishing Scrum as the Guide defines it and for the Scrum Team's effectiveness, so a Scrum Master who lets quality drop to make a date has let the Sprint stop being a Sprint. What the Guide asks for in concrete terms is narrow. Every Scrum event has to happen, each one has to stay inside its timebox and the Scrum Master has to cause the removal of whatever is blocking the Developers.
None of that reaches the contents of the Sprint. The Scrum Master does not decide how much work the Developers take on, does not assign it and does not approve the Increment, because the Developers select and plan the work while the Product Owner decides what the product needs. The commonest exam option here hands the Scrum Master the power to extend a Sprint so the Developers can finish. Nobody holds that power. A Sprint has a fixed length and ends on its date, and the only early ending available to anyone is cancellation by the Product Owner.
Why shorter Sprints cost less
A shorter Sprint buys more learning cycles and keeps the cost of being wrong inside a smaller window. As the Sprint gets longer, two problems grow together. The Sprint Goal has more time to become invalid before anybody acts on it, and complexity accumulates faster than the team can inspect it.
The length of a Sprint therefore sets the maximum amount of work that can turn out to rest on a wrong assumption. A team building a payments API on one week Sprints can lose a week to a misread specification, while a team on one month Sprints loses a month and will have spent most of that month building further endpoints on the same misreading.
Shortening a Sprint is not free, because every Sprint carries the fixed cost of its events and of taking 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 inside that to the Scrum Team.
Cancelling a Sprint
A Sprint may be cancelled when the Sprint Goal becomes obsolete, which usually means the goal was overtaken by something outside the team, such as a competitor shipping the same feature or a partner withdrawing the API the Sprint Goal depended on. Only the Product Owner has that authority. A team that has simply fallen behind still has a Sprint Goal that makes sense, so the Sprint runs to its date. Cancellations are uncommon, because a Sprint is short enough that finishing it usually costs less than stopping it.
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.