1.4 Scrum Definition, Rules, & Boundaries

1.4 Scrum Definition, Rules, & Boundaries

Official Scrum Guide Definition: Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. In simple terms, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat.

Understanding what Scrum mandates—and what it deliberately leaves open—is one of the most frequently tested concepts on the PSM I assessment. Many candidates fail because they confuse complementary engineering tools with non-negotiable Scrum rules.

---

Framework vs. Prescriptive Methodology

Scrum is not a traditional, step-by-step methodology. A methodology gives you detailed instructions for every scenario (e.g., "file Form 102B, write a 40-page software architecture document, perform code review on Tuesday").

Instead, Scrum is an intentionally incomplete framework. It defines only the minimal parts needed to implement Scrum theory. Rather than providing detailed instructions, the rules of Scrum guide people's relationships and interactions.

Because Scrum is a framework, it acts as a container: you can plug in various processes, techniques, methods, and practices (such as Kanban, XP, TDD, User Stories, or CI/CD pipelines) inside the Scrum container to improve your effectiveness.

 ┌────────────────────────────────────────────────────────────────────────┐
 │                       THE SCRUM FRAMEWORK CONTAINER                    │
 │                                                                        │
 │   Mandated Core Rules:                                                 │
 │   • 3 Accountabilities (PO, SM, Developers)                            │
 │   • 5 Events (Sprint, Planning, Daily, Review, Retro)                 │
 │   • 3 Artifacts & Commitments (PB/PG, SB/SG, Increment/DoD)            │
 │                                                                        │
 │   ┌────────────────────────────────────────────────────────────────┐   │
 │   │               COMPLEMENTARY PRACTICES PLUGGED IN               │   │
 │   │  User Stories • Story Points • Pair Programming • CI/CD        │   │
 │   │  Burndown Charts • Kanban Boards • Test-Driven Development     │   │
 │   └────────────────────────────────────────────────────────────────┘   │
 └────────────────────────────────────────────────────────────────────────┘

---

The All-or-Nothing Rule: Scrum Exists Only in Its Entirety

One of the most important paragraphs in the Scrum Guide states:

"While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices."

If an organization decides to drop the Sprint Retrospective because they are "too busy", or decides not to have a Product Owner, they are no longer doing Scrum. Omitting any core element destroys transparency and prevents effective inspection and adaptation.

On the exam, if a question asks what happens when a team skips an event or role, the correct answer highlights that empiricism fails and the process ceases to be Scrum.

---

What Scrum Mandates vs. What Scrum Leaves Flexible

The table below outlines the strict boundaries of the Scrum framework versus complementary practices that are completely optional:

---

Non-Negotiable Boundaries of Scrum Events

Scrum enforces strict boundaries regarding timeboxes and event execution:

1. The Sprint is a Container Event: All other events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) take place within the Sprint. Once a Sprint begins, its duration is fixed.
2. Fixed Timeboxes:
   • Sprint Duration: 1 month or less (typically 2 weeks).
   • Sprint Planning: Maximum 8 hours for a 1-month Sprint (usually shorter for shorter Sprints).
   • Daily Scrum: 15 minutes every working day for Developers.
   • Sprint Review: Maximum 4 hours for a 1-month Sprint.
   • Sprint Retrospective: Maximum 3 hours for a 1-month Sprint.
3. No Breaks Between Sprints: A new Sprint begins immediately after the conclusion of the previous Sprint. There are no "planning Sprints", "testing Sprints", or "buffer weeks" between Sprints.

---

Common Exam Scenarios & Anti-Pattern Traps

Anti-Pattern 1: Extending the Sprint to Finish Work

Trap Scenario: A team realizes on day 9 of a 10-day Sprint that they will not finish two backlog items. The Scrum Master extends the Sprint by 3 days.

• Scrum Boundary: NEVER extend a Sprint timebox. Sprints end on their scheduled date regardless of whether work is finished. Incomplete items return to the Product Backlog.

Anti-Pattern 2: Hardcoding Engineering Practices

Trap Scenario: A manager claims Scrum mandates writing User Stories with "As a... I want... So that..." syntax.

• Scrum Boundary: Scrum does not mandate User Stories or any specific syntax. The Product Owner can format Product Backlog items in whatever way is clear and useful.

Anti-Pattern 3: Skipping Events When Performance is High

Trap Scenario: A team has delivered 100% of their Sprint Goals for six consecutive months and decides they no longer need Sprint Retrospectives.

• Scrum Boundary: Omitting an event breaks empirical inspection and adaptation. High performance is maintained because of regular retrospectives.