5.2 Sprint Backlog & Sprint Goal

5.2 Sprint Backlog & Sprint Goal

Quick Answer: The Sprint Backlog is a plan created by and for the Developers. It is composed of three parts: the Sprint Goal (Why), the set of Product Backlog items selected for the Sprint (What), and an actionable plan for delivering the Increment (How). Its explicit commitment is the Sprint Goal, which remains fixed while the tactical plan adapts dynamically throughout the Sprint.

While the Product Backlog focuses on long-term product evolution, the Sprint Backlog is a tactical artifact designed for execution within a single Sprint. It creates transparency around the work the Developers plan to accomplish to achieve the Sprint Goal.

---

The Three Components of the Sprint Backlog

Many practitioners incorrectly believe the Sprint Backlog is merely a list of Jira tickets or user stories. The Scrum Guide explicitly defines the Sprint Backlog as a three-part structure:

1. The Why (Sprint Goal): The single, unifying objective established during Sprint Planning that provides focus and purpose for the Sprint.
2. The What (Selected PBIs): The set of Product Backlog items chosen from the Product Backlog for delivery in the current Sprint.
3. The How (Actionable Plan): The technical task breakdown, architectural design steps, or implementation strategy created by the Developers to turn the selected items into a Done Increment.

+-------------------------------------------------------------------+
|                         SPRINT BACKLOG                            |
|                                                                   |
|  1. SPRINT GOAL (WHY)                                             |
|     "Enable user checkout via credit card and PayPal."           |
|                                                                   |
|  2. SELECTED PRODUCT BACKLOG ITEMS (WHAT)                         |
|     - PBI #1: Payment Gateway Integration                         |
|     - PBI #2: Checkout UI Component                               |
|     - PBI #3: Receipt Email Service                               |
|                                                                   |
|  3. ACTIONABLE PLAN / TASKS (HOW)                                 |
|     - Create payment API endpoint [Dev A]                         |
|     - Build React form components [Dev B]                         |
|     - Set up unit & integration test suites [Dev C]               |
+-------------------------------------------------------------------+

---

The Commitment: Sprint Goal

The Sprint Goal is the formal commitment for the Sprint Backlog. It creates clarity and focus, encouraging Developers to work together as a cohesive unit rather than operating as isolated individuals working on separate tasks.

Benefits and Rules of the Sprint Goal

• Focus & Cohesion: A strong Sprint Goal gives Developers flexibility regarding how the objective is met. If an unexpected technical bottleneck occurs, Developers can negotiate scope reduction while keeping the Sprint Goal intact.
• Stability: The Sprint Goal does not change during the Sprint. Neither the Product Owner nor stakeholders can alter the Sprint Goal once the Sprint begins.
• Cancellation Authority: If external business conditions render the Sprint Goal completely obsolete (e.g., market shift, competitor release, corporate pivot), only the Product Owner has the authority to cancel the Sprint.

---

Developer Ownership & Real-Time Adaptation

One of the most heavily tested concepts on the CSM exam is the strict ownership of the Sprint Backlog.

Exclusive Ownership by Developers

• The Sprint Backlog is created by and for the Developers.
• Only the Developers can add, remove, or modify items in the Sprint Backlog during the Sprint.
• Neither the Scrum Master nor the Product Owner can assign tasks to Developers or mandate changes to the Sprint Backlog.

Dynamic Adaptation during the Sprint

As Developers execute their plan, they gain new technical insights. The Sprint Backlog is updated continuously:

• When new work is identified as necessary to reach the Sprint Goal, Developers add it to the Sprint Backlog.
• As tasks are completed or deemed unnecessary, remaining work is updated or removed.
• If Developers realize they have over-committed, they discuss scope reduction with the Product Owner. Conversely, if work finishes early, they collaborate with the PO to pull in additional Product Backlog items.

+-----------------------------------------------------------------------------------+
|                           SCOPE NEGOTIATION RULES                                 |
+-----------------------------------------------------------------------------------+
|  Allowed: Re-negotiating scope (PBI breakdown, technical design) with PO.         |
|  Allowed: Removing low-priority tasks that don't block the Sprint Goal.           |
|  Prohibited: Changing the Sprint Goal mid-Sprint.                                 |
|  Prohibited: Unilaterally adding new PBIs without Developer consent.             |
+-----------------------------------------------------------------------------------+

---

Artifact Comparison: Product Backlog vs. Sprint Backlog

---

Real-World Scenarios & CSM Exam Traps

Scenario 1: Product Owner Requesting Emergency Feature Mid-Sprint

Situation: On Day 4 of a 2-week Sprint, the Product Owner asks Developers to immediately stop working on their current Sprint Backlog items and implement a new urgent feature for a client. Scrum Solution: The Product Owner cannot unilaterally push work into the Sprint Backlog. The Developers assess whether accepting the new work jeopardizes the Sprint Goal. If it jeopardizes the Sprint Goal, the request must be declined or deferred to the next Sprint Planning. If the emergency is so extreme that the Sprint Goal becomes completely irrelevant, the Product Owner cancels the Sprint.

Scenario 2: Scrum Master Updating Task Statuses

Situation: During the Daily Scrum, the Scrum Master updates the sprint board and assigns open tasks to individual Developers. Scrum Solution: This is a clear Scrum anti-pattern. Developers self-manage and own the Sprint Backlog. The Scrum Master does not assign tasks or manage daily progress.

CSM Exam Traps to Watch For:

• Trap 1: "The Product Owner owns the Sprint Backlog because it contains Product Backlog items." -> False! The Developers own the Sprint Backlog exclusively.
• Trap 2: "Sprint Backlog tasks are locked and cannot be changed once Sprint Planning finishes." -> False! The Sprint Backlog evolves continuously as Developers learn more.
• Trap 3: "If a Developer falls behind, the Scrum Master should reassign their tasks to others." -> False! The Developers self-manage workload distribution internally.