6.2 Sprint Backlog & Sprint Goal

6.2 Sprint Backlog & Sprint Goal

Scrum Guide 2020: The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

If the Product Backlog answers “what might improve the product over time,” the Sprint Backlog answers “what are we trying to achieve this Sprint, and how will we do it?” Product Owners who treat the Sprint Backlog as their personal task list—or as a fixed contract of scope—miss core PSPO I questions about self-management and the Sprint Goal.

---

Three Parts of the Sprint Backlog

All three are required for a complete mental model. A shopping list of PBIs with no Sprint Goal is not a healthy Sprint Backlog. A slogan Goal with no plan is theater. A detailed task plan with no “why” invites thrash when stakeholders inject random work.

---

By and for the Developers; Visible and Real-Time

Scrum Guide 2020: The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned.

Unpack every phrase:

Plan by and for the Developers

• By Developers: they create the plan for how selected items become a Done Increment.
• For Developers: the artifact serves the people doing the work—not a status report for managers.

The Product Owner does not assign tasks inside the Sprint Backlog. The Scrum Master does not own the Sprint Backlog as a project schedule. Stakeholders do not edit it as a demand queue.

Highly visible

Opacity kills empiricism. The Sprint Backlog should be visible to the Scrum Team so progress toward the Sprint Goal can be inspected (especially at the Daily Scrum). “Visible” does not mean “open for anyone to force new work in.”

Real-time picture; updated throughout the Sprint

As Developers learn, they update the Sprint Backlog. Tasks appear, merge, or disappear. Estimates of remaining work change. That is normal inspection and adaptation inside the Sprint. Updating the plan is not the same as abandoning the Sprint Goal.

---

The Sprint Goal: Single Objective and Commitment

Scrum Guide 2020: The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

Created in Sprint Planning

The Sprint Goal is created during Sprint Planning. The whole Scrum Team collaborates. The Product Owner proposes how the product could increase its value and utility in the Sprint; Developers discuss capacity and approach; together they form a Goal that is coherent and achievable.

Single objective

“Single” is exam-critical. A Sprint Goal that is really five unrelated OKRs glued with the word “and” is not a Sprint Goal—it is a portfolio of initiatives. Coherence means Developers can make trade-offs together toward one outcome.

Examples of stronger vs. weaker Goals (illustrative):

Commitment by the Developers—with flexibility on exact work

The Sprint Goal is a commitment by the Developers, but it is not a promise that every selected Product Backlog item will ship unchanged. The Goal provides flexibility in the exact work needed to achieve it. That is how empiricism works inside the Sprint: protect the why; adapt the how and sometimes the what.

Outdated mental models that fail PSPO I:

• “Commitment means 100% of forecasted PBIs must finish or the team failed.”
• “If any selected item slips, the Sprint Goal automatically fails.”
• “The Sprint Backlog is a fixed scope contract signed by the Product Owner.”

---

When Work Turns Out Different: Negotiate Scope, Protect the Goal

Scrum Guide 2020: If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

This sentence is a Product Owner collaboration blueprint:

1. Learning appears — effort is higher, a dependency emerges, a simpler path appears, or a selected item is less valuable than assumed.
2. Developers drive the plan update — they own the Sprint Backlog plan.
3. Collaborate with the Product Owner — value and product intent may need rebalancing (which PBI slices still best serve the Goal?).
4. Negotiate Sprint Backlog scope — add, remove, or thin selected work as appropriate.
5. Without affecting the Sprint Goal — the single objective remains the north star unless it is truly obsolete (Sprint cancellation is a different, rare PO authority).

Product Owner behaviors that pass the exam

• Available for clarification and trade-off discussion mid-Sprint
• Willing to descope lower-value selected items to protect a valuable Goal
• Does not treat every stakeholder interruption as automatic Sprint Backlog content
• Does not cancel the Sprint merely because one PBI is harder than expected if the Goal can still be met

Product Owner behaviors that fail the exam

• Unilaterally rewriting the Sprint Backlog overnight based on a sales call
• Forcing Developers to keep all original PBIs and add new work with no Goal conversation
• Declaring the Sprint Goal optional so everything is “priority one”
• Using Daily Scrum as a personal status briefing and reassigning tasks

---

Sprint Backlog vs. Product Backlog (Keep the Boundary Clear)

New ideas discovered mid-Sprint usually go onto the Product Backlog unless they are negotiated into the Sprint because they serve the Sprint Goal. Dumping every new idea into the Sprint destroys focus.

---

Sprint Planning Link (Why / What / How)

Sprint Planning addresses three topics that map directly to the Sprint Backlog:

1. Why is this Sprint valuable? → Sprint Goal
2. What can be Done this Sprint? → selected Product Backlog items
3. How will the chosen work get done? → plan created by Developers

The Product Owner ensures attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. Developers forecast based on Definition of Done, past performance, and capacity. Nobody substitutes a manager’s spreadsheet for Developer forecast.

---

Quick Self-Check

• Sprint Backlog = why (Sprint Goal) + what (selected PBIs) + how (plan)
• Owned as a plan by and for Developers; highly visible; updated all Sprint
• Sprint Goal = single objective; Developer commitment; flexibility on exact work; created in Planning
• Unexpected work → negotiate scope with PO without affecting the Sprint Goal when possible
• PO influences value and clarifies; does not micromanage the Sprint plan