5.6 Product Backlog Item Attributes & Ordering
Key Takeaways
- Scrum Foundations LO 4.3 asks you to list at least three attributes of a Product Backlog item; the Scrum Guide names description, order, and size, and adds that attributes often vary with the domain of work.
- Scrum requires ordering, not prioritization — ordering produces a single sequence, which is a stronger and less ambiguous constraint than priority bands.
- Scrum does not mandate user stories, story points, or any estimation technique; these are popular practices, not framework rules.
- Value is not the only ordering input: risk, dependency, learning value, cost of delay, and regulatory deadlines all legitimately influence order.
- The Product Backlog is emergent — items are added, changed, reordered, and removed continuously as more is learned about the product.
Quick Answer: The Scrum Guide names three attributes of a Product Backlog item — a description, order, and size — and notes that "attributes often vary with the domain of work." The Product Backlog is ordered, not merely prioritized: a single sequence, top to bottom, with the Product Owner accountable for it.
Scrum Foundations Learning Objective 4.3 asks you to list at least three attributes of a product backlog item. The three named in the Guide are always a safe answer; value is a common and defensible fourth, since the Product Owner is accountable for maximizing product value.
The Named Attributes
| Attribute | What It Captures | Who Supplies It |
|---|---|---|
| Description | What the item is and what outcome it should produce | Product Owner, refined collaboratively with the Developers |
| Order | The item's position in the single sequence of the Product Backlog | Product Owner (accountable) |
| Size | Relative effort or complexity | The Developers who will do the work |
| Value (commonly added) | The benefit expected from the item | Product Owner |
The Guide's qualifier matters: attributes "often vary with the domain of work." A regulated medical-device backlog may carry a compliance-reference attribute; a marketing backlog may carry a campaign window. Scrum does not fix the schema.
Ordered, Not Prioritized
The Scrum Guide consistently uses ordered, and the word choice is deliberate. Prioritization typically produces buckets — a set of items all labelled "high." Ordering produces a sequence, which forces the harder question: of these two high-priority items, which comes first?
| Prioritization | Ordering |
|---|---|
| Categories: High / Medium / Low | A single top-to-bottom sequence |
| Ties are permitted and common | No ties — something is always next |
| Ambiguity survives the exercise | Ambiguity is forced out |
| Considers importance | Considers importance and sequence-dependent factors |
Ordering is what makes the Product Backlog directly consumable at Sprint Planning: the Developers can start from the top and work down, and "most valuable" has an unambiguous meaning.
What Legitimately Influences Order
Candidates often assume order is a pure business-value ranking. It is broader than that:
- Value — expected benefit to customers and the organization.
- Risk — high-uncertainty items are often ordered early so the risk is retired while there is time to react.
- Dependency — an item that unlocks several others may be ordered ahead of individually more valuable work.
- Learning value — an item that resolves a critical unknown may be worth doing first precisely because of what it teaches.
- Cost of delay — how quickly the item's value decays.
- External deadlines — regulatory or contractual dates the organization does not control.
- Effort — cheap high-value items may reasonably rise; the Product Owner weighs size against value.
All of these are the Product Owner's judgement to make. The organization must respect their decisions, which are visible in the content and ordering of the Product Backlog.
Granularity Varies by Position
Items near the top are small, well understood, and sized; items far down may be a single line capturing an idea. This is a direct consequence of the backlog being emergent — the Scrum Guide calls it "an emergent, ordered list of what is needed to improve the product" and "the single source of work undertaken by the Scrum Team." Refining a low-priority item that may never be built is waste; refining the top of the backlog is what makes Sprint Planning possible.
What Scrum Does Not Prescribe
This catches candidates who learned Scrum through a particular tool or trainer:
| Common Practice | Scrum's Actual Position |
|---|---|
| User story format ("As a… I want… so that…") | Not mentioned in the Scrum Guide. A useful convention, not a rule |
| Story points | Not mentioned. Scrum requires size, not any particular unit |
| Planning Poker | Not mentioned. A popular estimation technique |
| A formal "Definition of Ready" gate | Not a Scrum artifact. Readiness is described as being Done-able within one Sprint |
| Acceptance criteria per item | Not required by name, though clarifying expected behaviour is normal refinement work |
| MoSCoW / priority bands | Scrum requires a single order, not categories |
None of these are forbidden. The exam simply distinguishes what Scrum defines from what the industry commonly does. And note the sharpest distinction of all: acceptance criteria are item-specific, while the Definition of Done applies to every Increment. An item can satisfy its acceptance criteria and still not be Done.
Real-World CSM Scenario
A Product Owner maintains a backlog where 40 items are tagged "High" priority and the Developers ask which to start. The Product Owner replies, "They're all critical."
This is prioritization masquerading as ordering, and it silently transfers the ordering decision to whoever picks up work first — which means value decisions are being made by availability rather than by the person accountable for them. The Scrum Master coaches the Product Owner to produce a genuine sequence, using the forcing question: if we could ship only one of these next week, which one? Repeated, that question produces an order. The Product Owner keeps full authority over the result; what changes is that the decision is now explicit, visible, and inspectable — which is exactly what the ordering attribute exists to create.
Which three attributes of a Product Backlog item are explicitly named in the 2020 Scrum Guide?
Why does the Scrum Guide describe the Product Backlog as 'ordered' rather than 'prioritized'?
Which of the following is required by the Scrum framework?
A Product Owner orders a technically risky, low-visible-value item ahead of several higher-value features. Is this consistent with Scrum?