10.2 Ordering the Product Backlog
Key Takeaways
- The Scrum Guide’s primary language is that Product Backlog items are ordered—not merely labeled with priority numbers as the Guide’s core verb
- Ordering considers value and other factors such as risk, dependencies, learning, and cost of delay—not only a single static priority score
- Only the Product Owner is accountable for ordering the Product Backlog; stakeholders and others influence by informing and convincing the Product Owner
- Order is continuous and relative: top items should be ready enough for Sprint selection; lower items may remain larger and less detailed
- Multiple “number one priorities,” committee votes, or FIFO queues that ignore value break effective ordering
10.2 Ordering the Product Backlog
Scrum Guide 2020: 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; and, Ensuring that the Product Backlog is transparent, visible and understood.
Ordering is one of the four Product Backlog management duties—and one of the highest-yield PSPO I topics. Exam writers love traps that replace Product Owner judgment with committees, “P1 everything,” pure first-in-first-out queues, or vocabulary that treats “priority” as if the Guide’s central idea were a numeric field rather than sequence for value.
Critical Exam Language: Ordered (Not “Prioritized” as the Guide’s Primary Verb)
Scrum.org materials and the Scrum Guide emphasize that the Product Backlog is ordered. In everyday speech people say “prioritize.” On the exam:
| Prefer this reasoning | Risky / often wrong framing |
|---|---|
| Items are ordered so the Scrum Team always knows what is most important to consider next | “We prioritize with a 1–100 score and never change sequence” |
| Order is a decision about sequence toward the Product Goal and product value | “Priority” as a static label that does not affect what is selected |
| Relative order can change as evidence appears | MoSCoW categories where everything is “Must” |
Retired-wording watch: the 2017 Scrum Guide told the Product Owner to order items “to best achieve goals and missions.” The 2020 Guide dropped that phrase. It now defines the Product Backlog as “an emergent, ordered list of what is needed to improve the product” with the Product Goal as its commitment. Reason in 2020 terms — Product Goal, value, risk, dependencies, learning — rather than quoting retired 2017 language back at a question.
You will not fail solely for saying “priority” in casual language—but answers that reduce ordering to a fixed priority number while ignoring Product Owner accountability, emergence, and multi-factor judgment are weak. Answers that use ordered and explain why this item comes before that one match the Guide’s intent.
What “ordered” means operationally
- There is a sequence from top to bottom (or equivalent clarity about relative importance for selection).
- The top of the backlog is where Sprint Planning attention goes first.
- Order answers: If we can only pull a limited amount of work into the next Sprint(s), what should come first?
- Order is not the same as estimating size. Developers size; the Product Owner orders (and may use size as one input to value density judgments).
Order by Value—and Other Factors
Maximizing the value of the product does not mean “always ship the highest revenue feature next” in every context. Product Owner ordering is multi-factor judgment informed by goals, evidence, and constraints.
| Factor | Why it can move an item up or down |
|---|---|
| Value / outcome | Customer, commercial, strategic, or organizational benefit if delivered |
| Risk reduction | Security, operational, market, or technical risk that threatens value if deferred |
| Dependencies | Work that unlocks other high-value items or removes a bottleneck |
| Learning / validation | Experiments that resolve critical uncertainty cheaply |
| Cost of delay | Value lost for each period of waiting |
| Compliance / license to operate | Mandatory constraints without which the product cannot be used or sold |
| Progress toward Product Goal | Coherence with the current long-term objective |
Not only a priority number
A single numeric “priority” field can be a tool, but it is not a substitute for Product Owner thinking:
| Weak practice | Stronger practice |
|---|---|
| Everything scored “100” | Relative order forces trade-offs |
| Score set once a year | Order updates with Sprint Review evidence and new risks |
| Score ignores dependencies | Dependency-aware sequence so value can actually be realized |
| Score ignores learning | Small learning items ordered early when uncertainty dominates |
| Score set by average of stakeholder votes | PO accountable for order after input |
Exam trap: “The only correct ordering method is WSJF / RICE / story points / customer votes.” Scrum does not mandate a formula. Techniques can help; accountability and multi-factor value judgment remain with the Product Owner.
Value density intuition (without turning Scrum into a spreadsheet religion)
Product Owners often compare expected value to effort. A smaller item that delivers a large outcome or critical learning may outrank a huge feature with modest upside. Developers’ sizing informs that conversation; the PO does not invent story points for the team, and the team does not seize final order.
Only the Product Owner Is Accountable for Ordering
This rule is non-negotiable on PSPO I:
- Accountable for order: Product Owner
- May influence order: Stakeholders, customers, Developers, leadership—by providing information, constraints, evidence, and arguments
- Do not become co-owners of order: Committees that vote the backlog sequence as the decision mechanism
Stakeholders convince the Product Owner
Healthy pattern:
- Stakeholder brings evidence of user need, market risk, or opportunity.
- Product Owner inspects that input against Product Goal, value, and other factors.
- Product Owner adapts order when convinced—or explains why not, preserving transparency.
Unhealthy pattern:
- Steering committee ranks items by vote.
- Product Owner is a scribe who updates the tool.
- “Priority” flips weekly with politics, not evidence.
| Scenario | Correct stance |
|---|---|
| CEO wants a pet feature first | CEO can influence; PO still accountable for order toward product value and Goal |
| Developers see a critical technical risk | Developers advise; PO may order risk-reduction work high if it protects value |
| Sales wants every deal custom | PO orders for product value, not automatic “yes” to every deal |
| Two stakeholders both claim “P1” | PO resolves into a single order; both cannot be top |
Respect for Product Owner decisions (covered in self-managing / organizational chapters) is required for ordering to work. If anyone can override order silently, the Product Backlog is no longer a transparent single source.
Ordering Is Continuous and Relative
Continuous
Order is not only set at a quarterly roadmap workshop. Empiricism means:
- Sprint Reviews may change what should come next
- New risks can jump the queue
- Fulfilled or abandoned Product Goals change what “best order” means
- Refinement may split an item and re-place its children in the sequence
Relative detail follows order
A practical rule of thumb consistent with the Guide’s refinement guidance:
| Region of backlog | Typical state |
|---|---|
| Top | Smaller, clearer, ordered for near-term selection; ready enough to be Done in one Sprint |
| Middle | Emerging detail; may still be large |
| Bottom | Placeholders, ideas, larger epics; less precision is OK |
Do not spend the team’s refinement capacity polishing the bottom of the backlog while the top is not ready for Planning.
Ordering vs. selecting for the Sprint
- Ordering = Product Owner accountability for the Product Backlog sequence.
- Selecting work for a Sprint = Developers select items in Sprint Planning based on the Sprint Goal and their forecast of what they can complete to Done, collaborating with the Product Owner.
Developers do not reorder the Product Backlog as their accountability. They may pull lower items only when that serves the Sprint Goal and capacity—not as a way to bypass PO order for personal preference.
Anti-Patterns That Destroy Ordering
| Anti-pattern | Why it fails |
|---|---|
| Everything is top priority | No sequence; no focus; fake urgency |
| FIFO / “first request wins” | Ignores value, risk, and Product Goal |
| Committee vote as final order | Diffuses PO accountability; politics over outcomes |
| Separate priority lists per department | Breaks single source of work |
| Priority = who yelled last | Not empiricism; not value maximization |
| Frozen annual order | Fights emergence and inspection of outcomes |
| Order by pure effort (smallest first always) | Sometimes useful for flow; not always max value |
| Order by pure HiPPO (highest paid person’s opinion) without evidence | Can ignore users, risk, and Goal |
| “Technical backlog” ordered by engineering; “business backlog” by PO | Hidden trade-offs; dual sources of work |
Ordering and the Product Goal
The Product Goal is the long-term objective in the Product Backlog. Ordering should generally advance progress toward that Goal (and broader product value), not random popularity.
| Question to ask when ordering | Example |
|---|---|
| Does this item move us toward the Product Goal’s future state? | Self-serve renewal Goal → order checkout friction fixes high |
| Is there a dependency that must come first? | Identity service risk before multi-region launch items |
| What learning would change the rest of the order? | Fake-door test before a large personalization build |
| What risk, if deferred, destroys value? | Critical vulnerability before cosmetic UI polish |
Items that do not serve the Goal may still exist on the backlog, but they should not routinely outrank Goal-critical work without a transparent reason (for example, a compliance stop-ship).
Multi-Team Ordering
When multiple Scrum Teams share one product:
- Still one Product Backlog and one ordered sequence (or equivalent transparent ordering model)
- Still one Product Owner accountable for order
- Dependencies across teams make ordering and refinement harder—not a reason to clone three Product Owners with three conflicting orders
Scaling practices may help coordinate; they do not remove Product Owner accountability for the product’s backlog order.
Decision Aids vs. Mandated Techniques
Product Owners may use techniques such as:
- Cost of delay / WSJF-style thinking
- Opportunity scoring
- Risk matrices
- Customer interviews and outcome metrics
- Story mapping for structuring options before ordering slices
Scrum requires effective ordering, not a branded framework. If a question presents a technique as the only lawful Scrum method, be skeptical. If a question presents a technique as a helpful way the PO informs judgment while remaining accountable—that can be fine.
Quick Scenario Patterns for the Exam
- Stakeholders disagree → PO decides order after input; does not average votes into fake consensus order as the accountability model.
- Developers want different work → They advise on risk and feasibility; PO orders the Product Backlog; Developers self-manage how to achieve the Sprint Goal within selected work.
- New evidence mid-product → Reorder; backlog is emergent.
- Everything labeled critical → Force relative order; “all critical” is not an order.
- Someone says “prioritize” → Translate to ordered sequence for value and goals; avoid pure number worship.
Quick Self-Check
- Guide language center of gravity: ordered Product Backlog
- Order by value and other factors (risk, dependencies, learning, cost of delay)—not only a priority integer
- Only the PO is accountable for ordering; others convince and inform
- Order is continuous; top items ready for selection
- No dual backlogs, no eternal P1 pile, no committee-as-Product-Owner
Which statement best matches Scrum Guide language and intent for the Product Backlog?
A compliance risk and a popular revenue feature both claim urgency. How should ordering be reasoned about?
Stakeholders strongly disagree about what should be top of the Product Backlog. What is the correct accountability model?