1.4 Scrum Framework Overview & Core Rules

1.4 Scrum Framework Overview & Core Rules

Quick Answer: The Scrum framework consists of 3 Roles/Accountabilities (Product Owner, Developers, ScrumMaster), 5 Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), and 3 Artifacts (Product Backlog, Sprint Backlog, Increment) accompanied by 3 Commitments (Product Goal, Sprint Goal, Definition of Done). Scrum rules are non-negotiable; altering core rules creates "Scrum-But" and degrades empirical feedback loops.

Scrum is defined strictly in The Scrum Guide, authored and periodically updated by Scrum co-creators Ken Schwaber and Jeff Sutherland.

Per the Scrum Guide, Scrum is defined as: "A lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems."

---

The Immutable Rules of the Scrum Framework

Scrum is free, lightweight, and simple to understand, but difficult to master. Crucially, the Scrum Guide emphasizes that Scrum is immutable.

While an organization can implement partial Scrum practices, omitting or altering any core role, event, or artifact results in a pattern known as "Scrum-But" (e.g., "We use Scrum, BUT we don't hold Retrospectives"). While custom hybrid practices may work for certain teams, partial Scrum is not Scrum. Omitting parts covers up real operational impediments and weakens the empirical feedback loop.

---

The Structural "3-5-3" Framework (+3 Commitments)

Candidates must memorize the core structural components of Scrum and their explicit commitments for the CSM exam.

                    THE SCRUM FRAMEWORK
  +-----------------------------------------------------+
  |  3 ACCOUNTABILITIES (ROLES)                         |
  |   • Product Owner                                   |
  |   • Developers                                      |
  |   • ScrumMaster                                     |
  +-----------------------------------------------------+
  |  5 FORMAL EVENTS                                    |
  |   • The Sprint (Container Event)                    |
  |   • Sprint Planning                                 |
  |   • Daily Scrum                                     |
  |   • Sprint Review                                   |
  |   • Sprint Retrospective                            |
  +-----------------------------------------------------+
  |  3 ARTIFACTS  ------->  3 COMMITMENTS               |
  |   • Product Backlog  ──> Product Goal               |
  |   • Sprint Backlog   ──> Sprint Goal                |
  |   • Increment        ──> Definition of Done         |
  +-----------------------------------------------------+

---

The 3 Accountabilities (Scrum Roles)

Scrum eliminates traditional project hierarchy. There are no sub-roles, project managers, or team leads inside the Scrum Team. The entire Scrum Team is cross-functional and self-managing.

1. Product Owner (PO):

   • Core Accountability: Maximizing the value of the product resulting from the work of the Scrum Team.
   • Key Responsibilities: Effective Product Backlog management, developing and explicitly communicating the Product Goal, ordering Product Backlog items, ensuring Product Backlog transparency.
   • Authority: The PO is ONE person, not a committee. The organization must respect the PO's decisions.

2. Developers:

   • Core Accountability: Creating a usable, functional Increment each Sprint that satisfies the Definition of Done.
   • Key Responsibilities: Creating the plan for the Sprint (Sprint Backlog), instilling quality by adhering to the Definition of Done, adapting their plan daily toward the Sprint Goal, holding each other accountable as professionals.
   • Composition: Cross-functional experts (software engineers, testers, designers, architects, analysts) who perform the work.

3. ScrumMaster (SM):

   • Core Accountability: Establishing Scrum as defined in the Scrum Guide and fostering the Scrum Team's effectiveness.
   • Key Responsibilities: True leader who serves the Scrum Team and the broader organization; coaching self-management; causing the removal of impediments; facilitating Scrum events as requested or needed.

---

The 5 Formal Events & Timeboxing Rules

All Scrum events are timeboxed—meaning they have a strict maximum duration. Timeboxing instills focus, prevents wasteful meetings, and establishes a predictable cadence.

Note for Exam: For shorter Sprints (e.g., 2-week Sprints), event timeboxes are proportionally shorter (e.g., Sprint Planning is typically 4 hours or less; Retrospective is 1.5 hours or less).

---

The 3 Artifacts & Mandatory Commitments

Each artifact contains a mandatory commitment to ensure transparency and focus:

1. Product Backlog: An emergent, ordered list of what is needed to improve the product.

   • Commitment: Product Goal (describes a future state of the product which can serve as a target for the Scrum Team to plan against).

2. Sprint Backlog: The set of Product Backlog items selected for the Sprint, plus an actionable plan for delivering the Increment.

   • Commitment: Sprint Goal (the single objective for the Sprint, creating coherence and focus).

3. Increment: A concrete stepping stone toward the Product Goal. Multiple Increments may be created within a Sprint.

   • Commitment: Definition of Done (a formal description of the state of the Increment when it meets the quality measures required for the product).

---

Non-Negotiable Rules Governing Sprints

1. No Changes That Endanger the Sprint Goal: During a Sprint, no changes are made that would compromise achieving the Sprint Goal.
2. Quality Does Not Decrease: Quality goals do not drop mid-Sprint. If time runs short, scope is re-negotiated with the Product Owner.
3. Continuous Cadence: A new Sprint starts immediately after the conclusion of the previous Sprint (zero gap between Sprints).
4. Sprint Cancellation Authority: Only the Product Owner has the authority to cancel a Sprint, and only if the Sprint Goal becomes completely obsolete (e.g., major market collapse or corporate pivot).

---

Real-World CSM Scenario & Exam Failure Modes

Scenario: A engineering director orders a Scrum Team to extend their current 2-week Sprint by 4 extra days because three critical backlog items are unfinished. The director states: "We cannot hold our Sprint Review until all planned features are completed."

CSM Correct Response:

1. Enforce Timeboxing Rule: Sprints have fixed end dates. A Sprint NEVER gets extended to finish incomplete work.
2. Handle Incomplete Work: Unfinished items are moved back to the Product Backlog, re-estimated, and re-prioritized by the Product Owner.
3. Conduct Events On Schedule: Hold the Sprint Review on the scheduled date, presenting only items that meet the Definition of Done.
4. Retrospective Adaptation: Use the Retrospective to inspect why work was over-committed and adapt future Sprint Planning.