6.1 Product Backlog & Product Goal
Key Takeaways
- The Product Backlog is an emergent, ordered list of what is needed to improve the product and is the single source of work undertaken by the Scrum Team
- The Product Goal is the commitment of the Product Backlog: a future state of the product that serves as the long-term objective for the Scrum Team
- The Scrum Team fulfills or abandons one Product Goal before taking on the next; only one Product Goal is active at a time
- A product is a vehicle to deliver value with a clear boundary, known stakeholders, and well-defined users or customers—one product means one Product Backlog and one Product Owner
- Developers who will be doing the work are responsible for sizing; the Product Owner may influence trade-offs by ordering and clarifying value
6.1 Product Backlog & Product Goal
Scrum Guide 2020: The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Artifacts make work and value transparent so inspection and adaptation can happen. The Product Backlog is the Product Owner’s primary artifact. On PSPO I, almost every value, ordering, and refinement scenario bottoms out in how you treat this list and its commitment—the Product Goal.
What the Product Backlog Is (and Is Not)
| Attribute | Guide meaning | Exam implication |
|---|---|---|
| Emergent | Changes continuously as learning appears | Freezing a multi-quarter backlog without adaptation fights empiricism |
| Ordered | Items are sequenced so the Scrum Team knows what to take on next toward the Product Goal | Ordering is the Product Owner’s decision, not a committee vote |
| Single source of work | All work the Scrum Team undertakes comes from here | Shadow backlogs, side channels, and departmental mini-lists destroy transparency |
| Improves the product | Items describe what is needed to improve the product | Defects, experiments, enablers, and research can be valid PBIs—not only “features” |
The Product Backlog is never complete. It is a living artifact. New knowledge from users, the market, technology, or regulation changes content and order. That is expected—not a planning failure.
What does not belong as a parallel truth
- A sales “must-do” spreadsheet that bypasses the Product Owner
- A technical architecture backlog owned only by engineering leadership for the same product
- Multiple Product Owners each with their own backlog for one product
- A “committed roadmap” that the team must execute even when evidence says the Product Goal should change
Anyone who wants work done by the Scrum Team must get that work onto the Product Backlog through the Product Owner. Anyone who wants to change the Product Backlog must convince the Product Owner.
Commitment: The Product Goal
Each formal Scrum artifact has a commitment that reinforces empiricism and focus:
| Artifact | Commitment |
|---|---|
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done |
Scrum Guide 2020: The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
Characteristics of a Product Goal
- Future state of the product — not a project milestone calendar, not a list of projects, not a vague mission slogan detached from the product.
- Long-term objective for the Scrum Team — longer horizon than a single Sprint; shorter and more concrete than an unbounded vision that never constrains ordering.
- One at a time — the Scrum Team fulfills (or abandons) one Product Goal before taking on the next.
- Lives in the Product Backlog — it is not a secret slide; it is explicit and communicated so ordering and Sprint proposals can map to it.
Fulfill or abandon before the next. This is a high-yield line. You do not run three simultaneous Product Goals for one team and call them all “top priority.” You may abandon a Goal when evidence shows it is no longer the right long-term objective—then adopt another. Abandoning is honest adaptation; silently stacking Goals is a focus failure.
Product Goal vs. vision vs. Sprint Goal
| Concept | Horizon | Role |
|---|---|---|
| Product vision (common practice language) | Often broader / longer | Inspires direction; not a formal Scrum artifact commitment in the Guide |
| Product Goal | Long-term objective for the team | Commitment of the Product Backlog; focus for multi-Sprint work |
| Sprint Goal | One Sprint | Commitment of the Sprint Backlog; why this Sprint is valuable |
PSPO I cares that you can keep the Product Goal as the backlog’s commitment and not confuse it with the Sprint Goal or with a fixed annual feature list.
Product Definition: Boundary, Stakeholders, Users
The Guide defines a product as a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined users or customers. A product can be a service, a physical product, or something more abstract.
Why this matters for Product Owners:
- Clear boundary tells you what one Product Backlog covers. If “the product” is fuzzy, people invent multiple backlogs and multiple unofficial Product Owners.
- Known stakeholders are people with interest or influence; they provide input and inspect outcomes—they do not replace PO ordering.
- Users/customers are who value is for; ordering should advance outcomes for them relative to the Product Goal, not only internal politics.
One product → one Product Backlog → one Product Owner. Multiple Scrum Teams on the same product still share that single backlog, single Goal, and single PO. Scaling is done by adding teams, not by cloning Product Owners or backlogs.
Ready Items, Refinement, and Transparency
Product Backlog items at the top of the list should be refined enough that they can be Done within one Sprint. The Guide does not mandate a formal “Definition of Ready,” but it does state that Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in Sprint Planning. Refinement is the ongoing activity of breaking down and further defining items to add detail, such as description, order, and size.
| Refinement builds | Failure mode |
|---|---|
| Transparency of what “next” means | Vague top items force guesswork in Planning |
| Shared understanding between PO and Developers | PO throws unreadable tickets; Developers pad or refuse selection |
| Realistic forecasts for Sprint Planning | Giant epics selected as if they were Sprint-sized |
Refinement is a collaboration. The Product Owner remains accountable for effective Product Backlog management (Goal, creating/communicating items, ordering, transparency). Developers often help detail items and always own how work will be implemented.
Who Sizes? Who Influences Trade-offs?
Scrum Guide 2020: 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.
| Decision | Who |
|---|---|
| Size / estimate of work | Developers |
| Order of the Product Backlog | Product Owner |
| Trade-offs (split items, drop scope, accept risk, delay lower value) | PO influences with value context; Developers bring effort/risk |
| How much is selected into a Sprint | Developers forecast; Scrum Team collaborates in Planning |
Exam traps:
- Product Owner unilaterally assigns story points → wrong
- Stakeholders force size and Sprint capacity → wrong
- Developers reorder the Product Backlog without the Product Owner → wrong
- Product Owner clarifies value and splits a large item so the team can deliver a thinner slice of value sooner → correct trade-off influence
Product Owner Practices That Keep the Artifact Healthy
- Make the Product Goal explicit and map top PBIs to how they advance it.
- Order by value toward the Goal, incorporating risk, learning, dependencies, and cost of delay—not first-come-first-served.
- Keep one transparent backlog; kill shadow lists.
- Refine continuously so Sprint Planning is selection and planning, not discovery theater.
- Respect Developer sizing while actively discussing trade-offs that improve value density.
- Adapt the backlog after Sprint Reviews and real user evidence; emergence is a feature.
Common PSPO I Product Backlog Traps
| Trap | Why it fails |
|---|---|
| Multiple Product Backlogs for one product | Breaks single source of work and single PO accountability |
| Product Goal treated as optional vision poster | Product Goal is the commitment of the Product Backlog |
| Several concurrent Product Goals for one team | Guide: fulfill or abandon one before the next |
| PO estimates all items for “control” | Developers size the work |
| Only user stories allowed; tech work forbidden | Backlog holds whatever is needed to improve the product |
| Frozen annual backlog “for predictability” | Backlog is emergent; predictability comes from empiricism |
Quick Self-Check
Before moving on, state without notes:
- Product Backlog = emergent ordered single source of work to improve the product
- Commitment = Product Goal (future state; long-term; one at a time)
- Product = value vehicle with boundary, stakeholders, users/customers
- Ready ≈ can be Done in one Sprint; refinement creates transparency
- Developers size; PO influences trade-offs through value and ordering
According to the Scrum Guide 2020, which statement best describes the Product Backlog?
What is the commitment associated with the Product Backlog, and what constraint does the Guide place on it?
Who is responsible for sizing Product Backlog items, and how may the Product Owner influence that work?