Most PSM I candidates can name the Sprint Backlog as one of Scrum’s three artifacts. Fewer can explain precisely what it contains, who owns it, how it changes during a Sprint, and what happens when the work turns out to be harder than expected. Those four questions generate a significant share of exam items — and they’re where a lot of candidates drop points they shouldn’t.
This article works through the Sprint Backlog in the way the exam tests it: starting from the Scrum Guide’s exact definition, then addressing the ownership and adaptation questions that trip up prepared candidates, and finishing with the specific answer traps you’re most likely to see on exam day.
Everything here is drawn directly from the 2020 Scrum Guide. If a fact isn’t in the Guide, it isn’t in this article.
What the Sprint Backlog Actually Is
The Scrum Guide defines the Sprint Backlog with unusual precision. It has three parts:
- The Sprint Goal — the why behind the Sprint
- The set of Product Backlog items selected for the Sprint — the what the team will work on
- An actionable plan for delivering the Increment — the how the work will get done
That three-part structure matters because it’s tested directly. An exam question might ask what the Sprint Backlog is composed of, or which element represents the Sprint Goal’s relationship to the Sprint Backlog. The correct answer is that the Sprint Goal is part of the Sprint Backlog — it’s the commitment embedded within it — not a separate or interchangeable thing.
The Scrum Guide calls the Sprint Backlog “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.” That phrase “real-time picture” is doing meaningful work: it signals that the Sprint Backlog is not a one-time deliverable from Sprint Planning. It’s a live document that changes as the team learns more.
The Sprint Backlog’s Commitment: The Sprint Goal
Each of Scrum’s three artifacts has one commitment. For the Product Backlog, it’s the Product Goal. For the Increment, it’s the Definition of Done. For the Sprint Backlog, it’s the Sprint Goal.
The Sprint Goal is the single objective for the Sprint. The Scrum Guide is careful about how it characterizes this: “Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.” That sentence contains two exam-relevant claims. First, the Sprint Goal is committed to by the Developers — not the Product Owner, not the Scrum Master, not the organization. Second, the Sprint Goal deliberately allows for flexibility in the scope of work needed to achieve it. Scope is adjustable. The Sprint Goal is not.
This distinction — fixed goal, flexible scope — is one of the most frequently tested ideas in the entire exam.
Who Owns the Sprint Backlog?
The Scrum Guide states this directly: the Sprint Backlog is “a plan by and for the Developers.” Not the Scrum Team broadly. Not the Product Owner. The Developers.
This is one of the clearest ownership statements in the Guide, and it carries real implications for exam scenarios. The Developers are accountable for creating and maintaining the Sprint Backlog. The Sprint Backlog is among the things the Scrum Guide explicitly lists under Developer accountabilities: “Creating a plan for the Sprint, the Sprint Backlog.”
What does this mean in practice — and on the exam?
- The Product Owner cannot add items to the Sprint Backlog unilaterally during the Sprint.
- The Scrum Master does not manage the Sprint Backlog.
- Stakeholders and managers have no authority over what’s in the Sprint Backlog.
- Only Developers update the Sprint Backlog as new work is identified or tasks are completed.
When a scenario presents a CEO, a senior manager, or even the Product Owner trying to directly add work to an in-progress Sprint, the answer will never be “let them add it.” The correct path is always to route that pressure through the appropriate channel: the Scrum Team discusses the impact, and the Product Owner decides whether to renegotiate scope with the Developers — without compromising the Sprint Goal.
A Note on Product Owner Participation
The Product Owner isn’t excluded from the Sprint Backlog’s world entirely. During Sprint Planning, the whole Scrum Team — including the Product Owner — collaborates to select the Product Backlog items and define the Sprint Goal. The Product Owner proposes how the Sprint can increase value, and that proposal shapes the Sprint Goal the team commits to.
During the Sprint itself, if the Product Owner (or Scrum Master) is actively working on items in the Sprint Backlog, they participate as Developers. But their accountability for the Sprint Backlog as an artifact? That belongs to the Developers.
The Sprint Backlog Is a Living Document
This is where many candidates go wrong: they treat the Sprint Backlog as something that gets finalized at the end of Sprint Planning and then executed unchanged. That’s not what the Scrum Guide describes.
“The Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.”
Two things in that sentence are worth unpacking. First, the Sprint Backlog changes during the Sprint — Developers add tasks, remove tasks, update estimates, and adjust their plan as they learn what the work actually involves. Second, the Daily Scrum is the event where this inspection happens. The Scrum Guide defines the purpose of the Daily Scrum as: “to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”
That framing — adapt the Sprint Backlog — directly contradicts the notion of a frozen plan. The Daily Scrum isn’t a status report; it’s the mechanism by which Developers keep their plan current.
Fixed Goal, Flexible Scope: The Core Exam Principle
Understanding the Sprint Backlog correctly depends on holding one principle clearly in mind: the Sprint Goal is fixed for the duration of the Sprint; the scope of work in the Sprint Backlog is not.
The Scrum Guide puts it this way: “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 describes a real scenario — the Developers discover mid-Sprint that a selected item is larger, more complex, or dependent on something unexpected. The response is collaboration, not silence and overrun. Developers and the Product Owner talk. They can adjust what’s in scope for the Sprint. What they cannot do is change the Sprint Goal, extend the Sprint’s timebox, or simply drop items without discussing the implications.
Sprint Cancellation: The Rare Exception
There is one situation where the Sprint Goal itself becomes invalid: if circumstances change so drastically that the Sprint Goal becomes obsolete. In that case, the Scrum Guide allows the Sprint to be cancelled — but only by the Product Owner. No other person has this authority. A Sprint cancelled because items became technically difficult or because the team underestimated work is not a legitimate cancellation. Difficulty doesn’t make the Sprint Goal obsolete; changed business conditions might.
Sprint cancellations are rare. Expect the exam to present tempting scenarios where cancellation seems logical but isn’t — the correct answer is almost always to adapt scope while preserving the Sprint Goal, not to cancel.
Unfinished Items at Sprint’s End
When a Product Backlog item isn’t finished by the end of the Sprint — meaning it doesn’t meet the Definition of Done — the Scrum Guide is clear about what happens: it returns to the Product Backlog. It is not automatically carried over into the next Sprint’s backlog, and it cannot be presented at the Sprint Review as Done work.
The exact language: “If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.”
The Product Owner then decides whether to re-select that item in a future Sprint Planning, and at what priority. The Developers don’t simply assume they’ll pick it up next Sprint. The Product Owner orders the Product Backlog, and that ordering reflects current priorities — which may have shifted.
An unfinished item at Sprint’s end doesn’t mean the Sprint failed. The Sprint Goal is the measure of the Sprint, not the completion of every selected item. A Sprint where all selected items were completed but the Sprint Goal wasn’t met is a worse outcome than a Sprint where some items slipped but the Sprint Goal was achieved.
Common Exam Traps Around the Sprint Backlog
These are the specific misconceptions the PSM I exam exploits. Recognizing them in advance saves you from choosing a plausible-sounding wrong answer under time pressure.
Trap 1: The Product Owner orders or controls the Sprint Backlog
The Product Backlog is ordered by the Product Owner. The Sprint Backlog is owned by the Developers. If an answer option says the Product Owner should re-order the Sprint Backlog, determine what items the team works on during the Sprint, or approve changes to the Sprint Backlog, it’s wrong. The Product Owner’s role in the Sprint Backlog is influence and collaboration — not authority.
Trap 2: The Sprint Backlog and Sprint Goal are interchangeable
The Sprint Goal is the commitment within the Sprint Backlog. They are not the same thing, and they don’t have the same flexibility. The Sprint Goal is fixed; the Sprint Backlog’s scope can be negotiated. An exam question that conflates them is testing whether you’ve internalized this relationship.
Trap 3: The Sprint Backlog is finalized at Sprint Planning and doesn’t change
The Sprint Backlog is explicitly described as a real-time document that updates throughout the Sprint. The Daily Scrum’s purpose includes adapting the Sprint Backlog. Any answer that treats the Sprint Backlog as a static plan is describing a waterfall task list, not a Scrum artifact.
Trap 4: The Scrum Master manages or updates the Sprint Backlog
The Scrum Master’s job is to enable the team, coach Scrum, and remove impediments — not to manage artifacts. The Sprint Backlog is created and maintained by the Developers. A scenario where the Scrum Master “updates the Sprint Backlog” or “prioritizes the Sprint Backlog items” is describing something outside the Scrum Guide’s definition of the Scrum Master role.
Trap 5: Undone items mean the Sprint failed
The Sprint Retrospective and Sprint Review both provide opportunities to inspect and learn. Not completing every selected item isn’t automatically a Sprint failure. The Sprint Goal is the measure. If an answer says “the Sprint failed because not all items were completed,” it’s applying a waterfall completion lens to a Scrum concept. The correct framing is: items that don’t meet the Definition of Done return to the Product Backlog; the Sprint Goal is assessed on its own terms.
Trap 6: Work can be added to the Increment without meeting the Definition of Done
The Scrum Guide is unambiguous: “Work cannot be considered part of an Increment unless it meets the Definition of Done.” An answer that allows for partial credit — “nearly done,” “mostly complete,” or “the stakeholders agreed to accept it” — contradicts the Guide directly. The Definition of Done is binary. Work either meets it or it doesn’t.
A Quick Verification Checklist
Before sitting the exam, confirm you can answer each of these without hesitation:
- What are the three components of the Sprint Backlog? (Sprint Goal, selected PBIs, actionable plan)
- Which artifact contains the Sprint Goal as its commitment? (Sprint Backlog)
- Who is accountable for the Sprint Backlog? (Developers)
- Can the scope of the Sprint Backlog be renegotiated during a Sprint? (Yes — with the Product Owner, without affecting the Sprint Goal)
- What happens to a Product Backlog item that doesn’t meet the Definition of Done at Sprint’s end? (Returns to the Product Backlog)
- Who can cancel a Sprint, and under what condition? (Only the Product Owner, when the Sprint Goal becomes obsolete)
- What event’s purpose includes adapting the Sprint Backlog? (Daily Scrum)
If any of those made you pause, go back to the relevant section of the 2020 Scrum Guide and read the Sprint Backlog and Developers sections again. The Guide is 13 pages. The Sprint Backlog section is short. The payoff for knowing it precisely is disproportionately high given the number of exam questions it influences — directly and indirectly through scenarios.
Practice With Exam-Style Questions
Reading the Scrum Guide builds knowledge. Applying it under exam conditions is a different skill. The PSM I gives you 80 questions and 60 minutes — roughly 45 seconds per question. At that pace, you need the Sprint Backlog’s ownership, composition, and flexibility rules to be immediately retrievable, not something you piece together from first principles.
The PSM I Exam Simulator includes questions that specifically test Sprint Backlog concepts in the scenario format Scrum.org uses: a Scrum Master situation, several plausible options, and a correct answer that only makes sense if you’ve understood the underlying principle rather than memorized a definition. Working through those questions will tell you quickly whether your understanding is solid or whether there are gaps worth addressing before exam day.
Not ready to commit yet? The free 20-question PSM I practice test includes Sprint Backlog and artifact questions and gives you a baseline for where you stand.