SkarpSkarp

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.

27 min readen

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:

  1. Which parts of this scenario violate the emergent nature of the Product Backlog?
  2. How is ordering being mishandled or misunderstood?
  3. What is wrong with treating refinement as a fixed, formal "event"?
  4. 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?

  1. The Product Backlog is a fixed list of all requirements agreed at the start of the project.
  2. The Product Backlog is an emergent, ordered list of what is needed to improve the product.
  3. The Product Backlog is a prioritized list of user stories that cannot change during a Sprint.
  4. 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?

  1. A mandatory sixth Scrum event, time-boxed to 10% of the Sprint, where the Product Owner explains requirements.
  2. An optional event that happens once per release to finalize the Product Backlog before development starts.
  3. An ongoing activity in which the Product Owner and Developers collaborate to break down and further define Product Backlog items.
  4. 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.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself