4.3 Sprint Backlog Artifact & Ownership

4.3 Sprint Backlog Artifact & Ownership

While the Product Backlog represents the emergent, broad scope for the entire product, the Sprint Backlog represents the specific commitment and tactical plan for a single Sprint. According to the 2020 Scrum Guide, the Sprint Backlog is an artifact created by the Developers, for the Developers.

Mastering the Sprint Backlog is critical for passing the PSM I exam. Candidates must understand its exact composition, who owns it, how it evolves dynamically during execution, and how changes are managed without jeopardizing the Sprint Goal.

---

The Three Components of the Sprint Backlog

One of the most frequent exam questions asks candidates to identify the exact elements that make up the Sprint Backlog. The 2020 Scrum Guide defines the Sprint Backlog as a compound artifact made of three distinct components:

1. The Sprint Goal (Why): The overarching single objective for the Sprint.
2. Selected Product Backlog Items (What): The specific set of Product Backlog items chosen from the Product Backlog during Sprint Planning.
3. An Actionable Plan for Delivery (How): The technical tasks, architecture decisions, and operational steps decomposed by Developers to deliver an Increment meeting the Definition of Done.

+-----------------------------------------------------------------------------------+
|                             SPRINT BACKLOG COMPOSITION                             |
+-----------------------------------------------------------------------------------+
| 1. SPRINT GOAL (Why)       | The overarching commitment for the Sprint            |
| 2. SELECTED PBIs (What)    | User stories / features chosen during Sprint Planning|
| 3. DELIVERY PLAN (How)     | Tasks, sub-tasks, and technical implementation plan   |
+-----------------------------------------------------------------------------------+

---

Exclusive Ownership by the Developers

The Sprint Backlog belongs solely to the Developers:

• No External Assignment: No project manager, Scrum Master, Product Owner, or corporate manager has the authority to assign tasks from the Sprint Backlog to individual Developers or force new items into the Sprint Backlog during a Sprint.
• Self-Managing: Developers decide among themselves how to select, assign, execute, and deliver the work. They do not report task progress to a manager; they inspect progress together during the Daily Scrum.
• Visibility: The Sprint Backlog must be a visible, real-time picture of the work that the Developers plan to accomplish during the Sprint to achieve the Sprint Goal.

---

Dynamic Emergence and Daily Adaptation

A major misconception on the PSM I exam is that the Sprint Backlog is locked down during Sprint Planning and cannot change. In reality:

• Emergent Plan: The Sprint Backlog is updated continuously throughout the Sprint as Developers learn more about technical complexity, unexpected dependencies, or edge cases.
• Daily Inspection: During the Daily Scrum, Developers inspect their progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, updating remaining work estimates or adding newly discovered technical tasks.
• Task Decomposition: Developers do not need to decompose every selected PBI into micro-tasks during Sprint Planning. They must decompose enough work for the first few days, allowing the rest of the plan to emerge as work progresses.

---

Scope Modification Protocol During a Sprint

While the Sprint Backlog emerges dynamically, modifications must strictly follow Scrum rules:

1. Developer Authority

If Developers identify new tasks required to deliver a selected PBI, they add those tasks to the Sprint Backlog on their own authority.

2. Scope Renegotiation with the Product Owner

If Developers realize they have overcommitted (more work than capacity) or undercommitted (work finished early):

• They collaborate with the Product Owner to remove or add Product Backlog items.
• Items removed from the Sprint Backlog return directly to the Product Backlog for future prioritization.

3. Protecting the Sprint Goal

• Golden Rule: Scope may be clarified and renegotiated as more is learned, but no changes are made that endanger the Sprint Goal.
• Neither the Product Owner nor executive management can push scope changes that jeopardize the Sprint Goal.

---

Product Backlog vs. Sprint Backlog Comparison

---

Real-World PSM I Exam Traps

• Exam Trap 1: The Product Owner manages the Sprint Backlog and assigns tasks to Developers. False! The Sprint Backlog is owned exclusively by Developers. They self-manage task distribution.
• Exam Trap 2: The Sprint Backlog is frozen after Sprint Planning. False! The Sprint Backlog is emergent and continuously updated during the Sprint as Developers learn more.
• Exam Trap 3: Unfinished Sprint Backlog items are automatically marked as Done or carried over to the next Sprint Backlog without review. False! Incomplete items must return to the Product Backlog for the Product Owner to re-evaluate and re-order.
• Exam Trap 4: The Scrum Master creates the Sprint Backlog during Sprint Planning. False! The Sprint Backlog is created by the Developers, for the Developers.