Chapter 12 of 21
Artifacts I: Product Backlog, Product Goal, and Product Backlog Refinement
Trace how ideas become ordered Product Backlog items guided by a clear Product Goal, and unpack why refinement is ongoing work rather than a formal Scrum event.
Big Picture: Where These Artifacts Fit in Scrum
Zooming In
You will focus on three tightly linked Scrum concepts: Product Backlog, Product Goal, and Product Backlog refinement, all central to PSM I and to real Scrum practice.
Context in the Scrum Flow
You already saw Sprint Review (inspect Increment, adapt Product Backlog) and Sprint Retrospective (improve how the team works). Now you will study how the work itself is shaped.
Key Questions
You will learn how ideas become Product Backlog items, how the Product Goal guides ordering, why refinement is ongoing work, and how ordering copes with emergent requirements.
Empiricism Reminder
Scrum is founded on empiricism and lean thinking. The Product Backlog and Product Goal are the main levers to adapt what you will build based on evidence from real increments.
Product Backlog: Canonical Definition and Properties
Canonical Definition
Memorize: "The Product Backlog is an emergent, ordered list of what is needed to improve the product." Every word here is tested on PSM I.
Emergent
Emergent means the backlog is never finished. New items appear, existing ones are split, refined, or removed as the Scrum Team learns. Requirements are not frozen.
Ordered vs Just Listed
Ordered means items are in a clear sequence: 1st, 2nd, 3rd. This is stronger than just high/medium/low priority. The Product Owner is accountable for this ordering.
What Is Needed to Improve
Backlog items include features, bugs, technical work, experiments, UX, compliance, and more. All items exist because they help improve the product in some way.
One Backlog per Product
Exam trap: there is one Product Backlog per product, not per team. The Product Owner owns it, but it must stay transparent to the whole Scrum Team and stakeholders.
Product Goal: The North Star for the Product Backlog
Canonical Product Goal Definition
Memorize: "The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against."
Future State, Not Task List
The Product Goal describes what the product will be able to do in the future, like "90% of customers can open an account online in under 5 minutes."
Focus for the Scrum Team
The Product Goal is the single objective for the Scrum Team as a whole. They plan Sprints and order the Product Backlog as stepping stones toward it.
One Product Goal at a Time
There is one Product Goal per Product Backlog. When it is achieved or abandoned, the Product Owner sets a new Product Goal for the same product.
Exam Trap: Product vs Sprint Goal
Do not confuse Product Goal (longer-term product state) with Sprint Goal (single objective for one Sprint). PSM I often tests this distinction.
From Vision to Product Goal to Ordered Product Backlog
Vision vs Product Goal
Vision: "Help busy professionals eat healthier." Product Goal: "Users can receive personalized weekly meal plans and grocery lists based on their dietary preferences."
Deriving PBIs
To reach the Product Goal, the Scrum Team identifies PBIs: capture preferences, generate plans, generate grocery lists, allow swaps, analytics, plus technical and UX work.
Ordering for Value
The Product Owner orders PBIs so value toward the Product Goal appears quickly: preferences first, then plan generation, then grocery lists, then nice-to-haves.
Emergent and Changeable
As feedback arrives, the Product Owner may reorder PBIs. New ideas like "share meal plans" can be added; low-value items can be removed. The backlog keeps emerging.
Ordering vs Prioritization: Exam-Relevant Nuances
What Ordering Means
Ordering is a single sequence: each Product Backlog item has a unique position (1, 2, 3, ...). This is stronger and clearer than vague priority labels.
Fuzzy Priorities
Traditional prioritization might mark many items as "High" with no clear sequence. Scrum expects the Product Owner to resolve this into an ordered list.
Product Owner Accountability
The Product Owner is accountable for ordering the Product Backlog to maximize value, considering value, risk, learning, deadlines, and technical constraints.
Aligned with Product Goal
Items that advance the Product Goal are usually higher in the order. Items that do not support the current Product Goal may be pushed down or removed.
Exam Trap: Who Orders?
Developers can and should advise, but they do not own the ordering. Any exam option that says Developers order the Product Backlog is incorrect.
Emergent Requirements and Ongoing Adaptation
Why Requirements Emerge
In complex products, you cannot know everything up front. User behavior, markets, and technology change, so new needs and insights emerge over time.
Backlog as a Living List
Emergent requirements appear as new Product Backlog items. Existing items are split, refined, or removed as the Scrum Team learns more about the product.
Sprint Review as a Trigger
Sprint Review is a key moment where stakeholders and the Scrum Team inspect the Increment and adapt the Product Backlog based on what they have learned.
Ordering Adapts Too
The Product Owner may move high-value new items up the order and push low-value or obsolete items down or out. The order changes as reality changes.
Exam Signal: Fixed Backlogs
Any exam option that freezes the Product Backlog for a whole release contradicts its emergent nature and should be treated with suspicion.
Product Backlog Refinement: Definition and Nature
What Refinement Is
Product Backlog refinement is the ongoing activity of breaking down and further defining Product Backlog items into smaller, clearer items.
Not a Scrum Event
Scrum has five events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Refinement is not an event; it is ongoing work.
Who Refines?
Product Owner and Developers collaborate in refinement. The Scrum Master may facilitate, but refinement is mainly about clarifying future work.
Typical Refinement Tasks
Teams clarify acceptance criteria, split large items, estimate effort, and surface dependencies so that top items are "ready enough" for Sprint Planning.
Exam Trap: Time-Box
The Scrum Guide does not mandate a fixed time-box or percentage for refinement. Any exam answer that makes it a formal event or fixed 10% is incorrect.
Refinement in Action: Before and After
Starting Point: A Vague Item
Initial PBI: "Support online account opening for new customers." It is too large and unclear to plan a Sprint around.
Clarify with the Product Goal
The team recalls the Product Goal: "New customers can open an account online in under 5 minutes" and discusses what that really requires.
Split into Smaller PBIs
They create smaller PBIs: enter personal details, upload documents, auto-validate documents, and receive account confirmation.
Add Criteria and Estimate
They add acceptance criteria, consider regulations, estimate each PBI, and then the Product Owner reorders them for an MVP-first approach.
Outcome of Refinement
The backlog now has small, clear, ordered items that move toward the Product Goal and can be selected in Sprint Planning.
Thought Exercise: Spot the Non-Scrum Behaviors
Work through this scenario mentally and note where it conflicts with Scrum principles about Product Backlog, Product Goal, and refinement.
Scenario:
A company is launching a new e-commerce website. At the start of the project, the business analysts create a detailed requirements document with 300 "must-have" features. They convert each requirement into a Product Backlog item and mark them all as "High" priority. Management decides that the Product Backlog must not change until the first release is complete, to avoid "scope creep".
The Product Owner organizes a 4-hour "Backlog Refinement Event" every second Friday. Attendance is mandatory for all 20 stakeholders plus the whole Scrum Team. In this meeting, they walk through every single Product Backlog item line by line. Developers are not allowed to change the order of items; they must work strictly top-to-bottom, even when they discover that some items are technically impossible on the current platform.
Reflect on these questions:
- Which parts of this scenario violate the emergent nature of the Product Backlog?
- How is ordering being mishandled or misunderstood?
- What is wrong with treating refinement as a fixed, formal "event"?
- How might a clear Product Goal change how this team orders and refines their Product Backlog?
Write down or say out loud at least three concrete improvements you would suggest as a Scrum Master in this situation.
Quiz 1: Definitions and Nuances
Test your understanding of the canonical definitions and key nuances.
Which statement is fully consistent with the current Scrum Guide?
- The Product Backlog is a fixed list of all requirements agreed at the start of the project.
- The Product Backlog is an emergent, ordered list of what is needed to improve the product.
- The Product Backlog is a prioritized list of user stories that cannot change during a Sprint.
- The Product Backlog is a list of tasks defined by Developers for the next Sprint only.
Show Answer
Answer: B) The Product Backlog is an emergent, ordered list of what is needed to improve the product.
The canonical definition is: "The Product Backlog is an emergent, ordered list of what is needed to improve the product." The other options conflict with "emergent", misuse "prioritized", or incorrectly limit the backlog to one Sprint.
Quiz 2: Product Goal and Refinement Traps
Check how well you can spot exam-style traps about Product Goal and refinement.
Which of the following best describes Product Backlog refinement according to Scrum?
- A mandatory sixth Scrum event, time-boxed to 10% of the Sprint, where the Product Owner explains requirements.
- An optional event that happens once per release to finalize the Product Backlog before development starts.
- An ongoing activity in which the Product Owner and Developers collaborate to break down and further define Product Backlog items.
- A meeting where stakeholders reprioritize the Product Backlog without the Scrum Team present.
Show Answer
Answer: C) An ongoing activity in which the Product Owner and Developers collaborate to break down and further define Product Backlog items.
Product Backlog refinement is an ongoing activity, not a formal Scrum event. It typically involves the Product Owner and Developers collaborating to clarify and break down items. The Scrum Guide does not prescribe a fixed time-box or treat it as a sixth event.
Key Term Flashcards: Lock In the Canonical Phrases
Use these flashcards to reinforce exact wording and core ideas that often appear in PSM I questions.
- Product Backlog (canonical definition)
- The Product Backlog is an emergent, ordered list of what is needed to improve the product.
- Product Goal (canonical definition)
- The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
- Scrum Team focus (canonical phrase)
- The Scrum Team is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
- Emergent (in context of Product Backlog)
- Emergent means the Product Backlog is continuously evolving: items are added, split, refined, reordered, or removed as the Scrum Team learns and conditions change.
- Ordering vs prioritization
- Ordering is a clear sequence (1, 2, 3, ...), owned by the Product Owner, used to decide what to do next. Prioritization alone (e.g., High/Medium/Low) is often too fuzzy and is not the Scrum term.
- Who is accountable for ordering the Product Backlog?
- The Product Owner is accountable for ordering the Product Backlog to maximize the value of the product.
- Nature of Product Backlog refinement
- Product Backlog refinement is an ongoing activity where the Product Owner and Developers collaborate to break down and further define Product Backlog items. It is not a formal Scrum event.
- Connection between Product Goal and ordering
- The Product Goal provides a long-term target. The Product Owner orders Product Backlog items so that the items that most directly advance the Product Goal are usually higher in the list.
Key Terms
- Ordering
- The act of arranging Product Backlog items in a single, clear sequence (1, 2, 3, ...) to decide what should be done next, for which the Product Owner is accountable.
- Scrum Team
- The Scrum Team is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
- Product Goal
- The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
- Product Owner
- The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
- Product Backlog
- The Product Backlog is an emergent, ordered list of what is needed to improve the product.
- Emergent requirements
- Requirements that appear, change, or are better understood over time as the Scrum Team inspects increments and receives feedback, leading to continuous evolution of the Product Backlog.
- Product Backlog refinement
- An ongoing activity in which the Product Owner and Developers collaborate to break down and further define Product Backlog items so that they are smaller, clearer, and better understood.