The Product Backlog is the most frequently tested artifact on both the PSM I and PSPO I exams. It also generates some of the most wrong answers — not because candidates haven’t studied it, but because they bring the wrong mental model into the exam. The Scrum Guide defines the Product Backlog with specific, deliberate language, and the exam rewards precision. This article covers the concepts that trip up candidates most often, each one verified directly against the 2020 Scrum Guide.
What the Product Backlog Actually Is
The Scrum Guide defines the Product Backlog as “an emergent, ordered list of what is needed to improve the product.” Two words in that sentence carry more weight than they appear to: emergent and ordered.
Emergent means the backlog is not a fixed requirements document assembled at project kickoff. It evolves continuously as the Scrum Team and stakeholders learn more about the product and its users. Items are added, removed, refined, and reordered throughout the product’s life. Treating the Product Backlog like a static specification — or a signed-off requirements list — is one of the most common anti-patterns the exam probes.
The Guide also describes it as “the single source of work undertaken by the Scrum Team.” This phrase carries a critical implication: there is no parallel requirements document, no separate technical backlog, no shadow list maintained by another team. Everything the Scrum Team works on flows from one list.
“Ordered” Is Not “Prioritized” — and the Exam Knows the Difference
One of the most reliable exam traps is an answer choice that uses the word “prioritized” to describe the Product Backlog. The Scrum Guide uses “ordered” deliberately, and that distinction is tested.
Why does the language matter? Prioritization typically implies a tiered ranking where items within the same tier are treated as equally important. Ordering means something different: items are arranged in a specific sequence. The item at position one is more important than position two, which is more important than position three — there are no ties.
This distinction also shows up in what informs the ordering. Value is a major input, but it is not the only one. Dependencies between items, risk, learning sequencing, market timing, and technical constraints all play a role. The Product Owner weighs these factors to produce one coherent sequence. When exam answers describe the backlog as “prioritized by business value alone,” that answer is incomplete at best and wrong at worst.
The Product Owner’s Accountability for the Backlog
The Scrum Guide states that the Product Owner “is also accountable for effective Product Backlog management,” which includes:
- Developing and explicitly communicating the Product Goal
- Creating and clearly communicating Product Backlog items
- Ordering Product Backlog items
- Ensuring that the Product Backlog is transparent, visible, and understood
Two exam traps come directly from this section.
Delegation Does Not Transfer Accountability
The Guide adds: “The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.”
This is tested directly. An exam question might describe a scenario where the Product Owner has delegated backlog ordering to the Scrum Master or a senior Developer, then ask who is accountable for the Product Backlog. The correct answer is always the Product Owner — regardless of who is doing the day-to-day work. Delegation transfers a task; it does not transfer accountability.
One Person, Not a Committee
“The Product Owner is one person, not a committee.” This line appears verbatim in the Scrum Guide and surfaces on the exam in several forms. Organizations sometimes implement product ownership through a steering group or approval committee to satisfy internal governance. The Scrum Guide does not support this arrangement.
The PO may represent the needs of many stakeholders in the Product Backlog, but a single individual holds the accountability. If an exam scenario describes a “Product Owner team” jointly ordering the backlog, that description does not align with Scrum as defined.
The Guide also reinforces the PO’s authority in a way that’s frequently tested: “Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.” Stakeholders do not add items directly. Developers do not reorder items without the PO’s involvement. The PO is the gatekeeper of the backlog.
Who Selects Items for the Sprint
Many candidates assume the Product Owner determines how many Product Backlog items enter a Sprint. This is false, and the exam tests it directly.
The Scrum Guide is explicit on this point: “Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.”
The Product Owner’s role in Sprint Planning is different from selecting items. The PO ensures attendees are prepared to discuss the most important backlog items and how they map to the Product Goal. The PO proposes a Sprint Goal. But the selection of specific items — and the judgment of how much can realistically be accomplished — belongs to the Developers.
The Guide reinforces this: “Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.”
If an exam answer states that the Product Owner decides how many items go into the Sprint, that answer is incorrect.
Who Sizes the Work
Closely related to Sprint selection is the question of estimation. The Scrum Guide states: “The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.”
This is a clear division: the PO brings business context (value, urgency, dependencies), the Developers provide effort estimates. The PO cannot assign story points or size estimates to items. That authority belongs to the people who will do the work.
This distinction trips up PSPO I candidates in particular. A common wrong answer pattern looks like: “The Product Owner sizes items based on their business value.” Business value and effort are different dimensions. The PO is accountable for value maximization; Developers are responsible for understanding the effort required to deliver it.
Product Backlog Refinement Is an Ongoing Activity, Not a Ceremony
The Scrum Guide defines refinement as “the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.”
Notice what is absent: there is no prescribed refinement meeting in Scrum. The five formal events in Scrum are the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Refinement is not one of them.
Candidates who learned Scrum under older terminology — where “backlog grooming” was treated as a regular ceremony — sometimes get tripped up by questions asking which events Scrum prescribes, or by scenarios that describe a team skipping their refinement meeting. Refinement can happen at any point during the Sprint. It is a continuous activity, not a time-boxed event.
One older data point to be aware of: the 2017 Scrum Guide included guidance suggesting Developers spend roughly no more than 10% of their capacity on refinement. The 2020 Scrum Guide removed this figure entirely. Candidates using outdated study materials may carry this number into the exam incorrectly — and select answers based on it.
What should a well-refined item look like? The Guide says items “that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.” Note that the Scrum Guide does not define a formal “Definition of Ready” — that term does not appear in the 2020 Guide. Items must simply be understood well enough and small enough to be completed within a Sprint.
The Product Goal: The Backlog’s Commitment
The 2020 Scrum Guide introduced a significant structural change: each of the three Scrum artifacts now has a commitment. For the Product Backlog, the commitment is the Product Goal.
The Guide describes the Product Goal as “a future state of the product which can serve as a target for the Scrum Team to plan against.” It also states: “The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.”
Several exam-relevant points follow from this:
- The Product Goal lives inside the Product Backlog — it is not a separate artifact or external document.
- A Scrum Team pursues one Product Goal at a time. Multiple active Product Goals for a single product are not consistent with the Guide.
- A Product Goal can be abandoned. The team is not locked in indefinitely if circumstances change substantially enough to make the goal irrelevant.
- The rest of the Product Backlog “emerges to define ‘what’ will fulfill the Product Goal” — meaning the backlog exists in service of the goal, not the other way around.
Both PSM I and PSPO I candidates should know the artifact-commitment pairings precisely: Product Backlog and Product Goal, Sprint Backlog and Sprint Goal, Increment and Definition of Done.
One Product Backlog Per Product — Even With Multiple Teams
When multiple Scrum Teams work on the same product, the Scrum Guide specifies that they share one Product Backlog, one Product Goal, and one Product Owner: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”
Exam questions sometimes present a scenario with two or three Scrum Teams on the same product and ask what structure is correct. The answer involves a single Product Backlog and a single Product Owner — not a separate backlog per team.
Why does this matter beyond memorization? A shared backlog gives the Product Owner a unified picture of all outstanding work and enables coherent ordering decisions across the entire product. If each team maintained its own backlog, the PO would lose visibility and the ability to make value-maximizing tradeoffs across the product as a whole.
What Happens to Items That Don’t Meet the Definition of Done
The Guide states: “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.”
This rule generates several exam scenarios. Common patterns:
- A team finishes eight of ten Sprint Backlog items. The two unfinished items return to the Product Backlog — they do not automatically carry forward into the next Sprint.
- An item that fails quality checks during the Sprint returns to the Product Backlog, not to a separate “spillover” list.
- The Product Owner decides what happens to returned items: they may be re-ordered higher, broken down into smaller pieces, or deprioritized depending on current business needs.
The underlying principle is transparency. If an item returns to the backlog rather than quietly rolling over, the Product Owner has a visible signal that something needs attention — whether that means better refinement before the next Sprint, or a decision to not pursue the item at all.
Putting It Together for the Exam
The Product Backlog looks deceptively simple — an ordered list of work for the Scrum Team. But the Scrum Guide’s language is precise, and both the PSM I and PSPO I exams exploit every place where candidates make assumptions rather than reading carefully.
The concepts that most reliably generate wrong answers:
- Using “prioritized” when the Guide says “ordered”
- Assuming the Product Owner decides how many items go into a Sprint (Developers do)
- Assuming the Product Owner sizes items (Developers do)
- Treating refinement as a fixed ceremony rather than an ongoing activity
- Thinking delegation of backlog management transfers accountability away from the PO
- Forgetting that the Product Goal is the backlog’s commitment and lives inside the backlog
- Believing multiple teams on one product need separate backlogs
- Assuming unfinished Sprint items automatically carry forward (they return to the Product Backlog)
Each of these has a clear answer in the 2020 Scrum Guide. The best preparation is to read the Guide carefully, then practice applying it to scenarios — because the exams test judgment and application, not just recall.
The PSM I Exam Simulator and PSPO I Exam Simulator each include hundreds of scenario-based questions on Product Backlog management, designed to surface exactly these misunderstandings before exam day. If you want to gauge where you stand right now, start with a free 20-question sample: free PSM I practice test or free PSPO I practice test.