4.1 The Sprint

Why the Sprint Matters on PSM I

The Sprint is the most heavily tested concept on the Professional Scrum Master I (PSM I) assessment because every other event lives inside it. The 2020 Scrum Guide describes Sprints as "the heartbeat of Scrum, where ideas are turned into value." Master the rules of the Sprint and most event questions become mechanical.

A Sprint is a fixed-length event of one month or less. "Fixed" is the load-bearing word: the duration is chosen once and never stretches to absorb unfinished work. The team picks a cadence — one, two, three, or four weeks — and holds it. Consistency is the point: a steady length makes velocity, capacity, and the Definition of Done meaningful from one Sprint to the next, which is why the Guide warns that varying the length damages transparency.

When one Sprint ends, a new Sprint starts immediately. There is no gap, no "Sprint zero" between Sprints, no planning week, and no hardening or stabilization Sprint. PSM I writers love to slip a "buffer day" or "integration week" into a scenario; recognize it as a violation. The only thing between two Sprints is the Sprint Retrospective of the old Sprint and the Sprint Planning of the new one, both of which belong inside a Sprint.

The Sprint as a Container

All work to accomplish the Product Goal — Sprint Planning, every Daily Scrum, the Sprint Review, and the Sprint Retrospective, plus the actual development — happens inside the Sprint. The Sprint is not a fifth event sitting beside the other four; it is the envelope that contains them.

Because the Sprint is a container, the 2020 Scrum Guide reduced the total count of events to five: the Sprint plus the four events held within it. A frequent trap counts the Sprint Review and Retrospective as "outside" the Sprint — they are the last events that occur before the Sprint concludes, but they are firmly inside it.

Constraints During an In-Progress Sprint

The Scrum Guide places four protections around an active Sprint:

• No changes are made that would endanger the Sprint Goal. The Sprint Goal is the commitment that gives the Developers focus and coherence.
• Quality does not decrease. Teams never trade the Definition of Done to hit a date.
• The Product Backlog is refined as needed. Refinement is an ongoing activity, not a formal event.
• Scope may be clarified and renegotiated with the Product Owner as more is learned.

This last point is the classic exam distinction. Changing the Sprint Backlog — adding, dropping, or reshaping items — is allowed, provided the Sprint Goal survives. The Sprint Goal, not the individual backlog item, is the guardrail. So when a question asks whether new work can enter a running Sprint, the right lens is: does it endanger the Sprint Goal? If not, the Developers and Product Owner can renegotiate scope.

Cancelling a Sprint

A Sprint can be cancelled if the Sprint Goal becomes obsolete — for example, the company pivots, the market shifts, or the underlying need disappears. Only the Product Owner has the authority to cancel a Sprint. Stakeholders, the Scrum Master, the Developers, or management may influence the decision, but the authority sits with the Product Owner alone. This is a high-frequency PSM I item: "Who can cancel a Sprint?" The answer is always the Product Owner, and only because the Sprint Goal is obsolete — never because the work is hard, late, or the team is behind.

Sprint cancellations are uncommon and disruptive. When one happens, any completed and Done work is reviewed; if it is potentially releasable, the Product Owner typically accepts it. Incomplete Product Backlog items return to the Product Backlog for re-estimation and future selection.

Shorter Sprints Reduce Risk

Shorter Sprints generate more learning cycles and limit the risk of cost and effort to a smaller time frame. Think of each Sprint as a bet on the Sprint Goal: a shorter Sprint is a smaller bet with faster feedback. If the bet is wrong, less is lost and the team corrects sooner. This is empiricism applied at the level of cadence — transparency, inspection, and adaptation happening more often. The trade-off is overhead: more Sprints mean more Planning, Reviews, and Retrospectives, so the team balances learning speed against ceremony cost.

Worked Scenario: New 'Urgent' Work Mid-Sprint

Consider a realistic PSM I scenario. " An inexperienced Scrum Master might extend the Sprint, force the Developers to drop the Definition of Done, or let the sales leader cancel the Sprint. All three are wrong. The correct reasoning chain is: (1) the Sprint length is fixed — it cannot be extended; (2) quality does not decrease — the Definition of Done is not negotiable; (3) scope can be renegotiated with the Product Owner if the Sprint Goal is not endangered; and (4) only the Product Owner cancels a Sprint, and only for an obsolete Sprint Goal.

So the right move is a conversation with the Product Owner about whether the new work fits without endangering the Sprint Goal, or whether it belongs in the Product Backlog for a future Sprint. The Scrum Master facilitates this and shields the Developers from a direct end-run.

Self-Management and the Sprint

The Sprint is also where the Scrum Team's self-management shows up most concretely. Within the Sprint, the Developers decide who does what, when, and how — no one outside the Scrum Team directs them, and the Scrum Team has no sub-teams or hierarchies. The Sprint's fixed boundary is what makes self-management safe for the organization: stakeholders get a predictable inspection point at the Sprint Review, and in return the team gets an uninterrupted, focused container in which to do the work.

Stable Sprint length, a protected Sprint Goal, and steady quality are the three guarantees the team offers; autonomy inside the box is what it gets back.