5.3 Sprint Backlog & the Sprint Goal

Composition: Why, What, How

The Sprint Backlog is composed of three things, and the 2020 Scrum Guide frames them as a why/what/how triad that is one of the most heavily tested ideas on the PSM I:

1. The Sprint Goal — why the Sprint is valuable (the single objective).
2. The set of Product Backlog items selected for the Sprint — what will be done.
3. An actionable plan for delivering the Increment — how the work will get done.

If an exam answer describes the Sprint Backlog as only "the list of tasks" or only "the selected items," it is incomplete — the Sprint Goal and the delivery plan are integral parts of the artifact. The Sprint Backlog is the Sprint's real plan, not a Gantt chart, not a board, and not the Sprint forecast alone.

By the Developers, for the Developers

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 to achieve the Sprint Goal. Because it is real-time, the Developers update it throughout the Sprint as they learn — adding, removing, or re-shaping tasks. It is updated at least every Daily Scrum, but not only then; learning can change the plan at any moment.

Crucially, the Sprint Backlog is not owned by the Scrum Master or the Product Owner, and no one outside the Developers may add work to it during the Sprint. The Scrum Master coaches the Developers to keep it transparent; the Product Owner collaborates on scope but does not control the plan. A classic trap: a manager or Product Owner "adds an urgent item to the Sprint Backlog" mid-Sprint — only the Developers decide what is in their plan, and they would do so in service of the Sprint Goal.

The Sprint Goal Commitment

The Sprint Goal is the single objective for the Sprint and is the commitment for the Sprint Backlog. Although it is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal is created during Sprint Planning (the why topic) and then added to the Sprint Backlog. There is exactly one Sprint Goal per Sprint — never zero, never several.

The Sprint Goal creates coherence and focus, encouraging the Scrum Team to work together rather than on separate, unrelated initiatives. It also lets the Developers inspect their progress toward a single, shared objective at every Daily Scrum.

Committed Yet Flexible — Renegotiating Scope

The most important nuance for the exam is that the Sprint Goal is firm while the scope is negotiable:

• If the Developers learn that the work will be different than expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog — adding, dropping, or reshaping items — without affecting the Sprint Goal.
• The Sprint Goal itself does not change within the Sprint. If the Sprint Goal becomes obsolete, the appropriate response is to cancel the Sprint — and only the Product Owner has the authority to cancel a Sprint.
• Should the work turn out to be impossible to complete fully, the team still pursues the Sprint Goal; scope flexes, the objective holds.

A correct mental model: the Sprint Goal is the destination the whole team committed to reach; the selected items and plan are the route, and a good team reroutes as the terrain reveals itself. Distractors that say "the Sprint Goal must be honored exactly as the original task list" or "the Scrum Master changes the Sprint Goal" are wrong on both the flexibility point and the authority point.

Worked Scenario: Scope Flexes, Goal Holds

Suppose the Sprint Goal is "Let users reset their password without contacting support." The Developers selected five items: email reset, SMS reset, security questions, rate-limiting, and an audit log. Mid-Sprint they discover the SMS gateway integration is far larger than expected. Because the Sprint Goal is still achievable via email reset alone, the Developers talk with the Product Owner and renegotiate scope — they drop SMS reset for now and add a small "reset link expiry" item that strengthens the goal. The Sprint Goal is untouched; only the what and how changed. This is textbook 2020-Guide behavior and a frequent exam item.

Contrast that with a case where the company pivots and password reset is no longer wanted at all. Now the Sprint Goal itself is obsolete, so the correct action is to cancel the Sprint — and only the Product Owner may do so. The exam often blends these two situations to see if you can tell "renegotiate scope" apart from "cancel the Sprint."

Sprint Backlog Facts That Get Tested

Keep the ownership boundary crisp: the Product Owner owns the Product Backlog and the Product Goal; the Developers own the Sprint Backlog and the Sprint Goal commitment. Confusing these owners is one of the most common artifact-question errors on the PSM I.