3.1 The Sprint Event & Container Nature

3.1 The Sprint Event & Container Nature

In Scrum, the Sprint is the heart of empirical process control. It is a fixed-length event of one month or less created to establish consistency and predictability. More fundamentally, the Sprint serves as the container for all other Scrum events—Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective. Every piece of work necessary to achieve the Product Goal, including the management and refinement of the Product Backlog, takes place within the boundary of a Sprint.

+-----------------------------------------------------------------------------------+
|                                    THE SPRINT                                     |
|  +-----------------+  +-----------------+  +-----------------+  +--------------+  |
|  | Sprint Planning |  |   Daily Scrum   |  |  Sprint Review  |  | Retrospective|  |
|  |  (Max 8 hours)  |  |  (15 mins/day)  |  |  (Max 4 hours)  |  | (Max 3 hours)|  |
|  +-----------------+  +-----------------+  +-----------------+  +--------------+  |
+-----------------------------------------------------------------------------------+

---

The Container Concept and Fixed Timeboxing

A timebox is a maximum unit of time allocated to achieve a specific objective or complete an event. In Scrum, timeboxes are strict boundaries, not flexible targets. Sprints are limited to one calendar month or less for several critical reasons:

1. Limiting Risk: Keeping Sprint durations short limits the financial and operational risk to at most one month's expenditure.
2. Frequent Feedback Loops: Shorter Sprints ensure frequent inspection and adaptation against real stakeholder feedback and market movements.
3. Manageable Complexity: Complexity increases exponentially as time horizons expand. Short timeboxes force work to be decomposed into small, understandable increments.

When a Sprint begins, its duration is fixed and cannot be shortened or extended. If the Developers realize three days before the Sprint ends that they will not complete all selected Product Backlog items, the Sprint duration does not expand. Conversely, if all items are completed early, the Sprint does not end prematurely; instead, the Developers collaborate with the Product Owner to select additional valuable refinement or backlog items for the remaining time.

---

Back-to-Back Cadence: No Gaps or Phase Sprints

A core rule of the Scrum framework is that a new Sprint starts immediately after the conclusion of the previous Sprint. There are no empty calendar days, no 'planning days', and no buffer periods between Sprints.

Non-Existent 'Special Sprints' in Scrum

On the PSM I exam, scenarios frequently present traditional project management concepts disguised as Sprints. You must recognize that the following concepts do not exist in authentic Scrum:

---

What Occurs During a Sprint?

During a Sprint, four fundamental principles must be observed:

1. No Changes That Endanger the Sprint Goal: No member of the Scrum Team or external management may introduce scope changes or new requirements that compromise the single commitment of the Sprint—the Sprint Goal.
2. Quality Standards Do Not Decrease: Quality is never sacrificed to meet a deadline. Work that fails to meet the Definition of Done cannot be counted toward the Increment or demonstrated during the Sprint Review.
3. Continuous Product Backlog Refinement: The Product Backlog is continuously refined as needed by the Scrum Team to prepare future items for upcoming Sprints.
4. Scope Clarification and Re-negotiation: Scope is not rigid. As Developers learn more technical details during implementation, they clarify and re-negotiate scope with the Product Owner without altering the underlying Sprint Goal.

---

Sprint Cancellation: Rules and Procedure

While rare, a Sprint can be cancelled before its timebox expires. The Scrum Guide 2020 specifies strict boundaries around cancellation:

Who Can Cancel a Sprint?

Only the Product Owner has the authority to cancel a Sprint. Neither management, the Scrum Master, nor the Developers have the power to cancel a Sprint. The Product Owner may do so under the influence or advice of stakeholders, Developers, or the Scrum Master, but the ultimate decision rests solely with the Product Owner.

When Can a Sprint Be Cancelled?

A Sprint should be cancelled only if the Sprint Goal becomes obsolete. This occurs when the organization changes strategic direction, market conditions shift drastically, or underlying technology renders the goal irrelevant. A Sprint is never cancelled simply because the Developers are behind schedule, technical work is harder than expected, or items will not be finished.

What Happens Upon Cancellation?

When a Sprint is cancelled:

• Any completed and accepted Product Backlog items that meet the Definition of Done are reviewed. If they represent a usable Increment, the Product Owner may accept them.
• All incomplete Product Backlog items are re-estimated and returned to the Product Backlog so they can be prioritized for future Sprints.
• The Scrum Team immediately enters Sprint Planning for a new Sprint.

---

PSM I Exam Traps & Empirical Guidance

Exam Trap Alert: Questions often ask: "What should the Scrum Master do if the Developers realize midway through a 2-week Sprint that they will only finish half of the committed items?"

Correct Empirical Approach: The Scrum Master encourages the Developers to collaborate with the Product Owner to re-negotiate the scope of the Sprint Backlog (e.g., removing lower-priority items) while preserving the Sprint Goal and maintaining quality standards. The Sprint length is never extended, and the Sprint is never cancelled due to capacity miscalculations.