Overview
Working with the Product Backlog is the fifth and largest CSPO learning objective category, with eight objectives. It opens with the difference between outcome, the change in customer behavior or business results, and output, the features and items delivered. From there you list ways to maximize outcomes while doing less, define product economics terms such as cost of delay and return on investment, and describe value from the viewpoints of customers, users, the business and the team. You also list techniques to measure value, build a Product Backlog that serves a Product Goal, write an item that states its desired outcome and value, and practise a refinement approach.
These objectives come together in hands-on backlog work during the course. CSPO has no test, so expect to apply them in exercises rather than answer timed questions.
How it's tested
CSPO has no exam, so practice items for this category are self-checks on backlog judgment. They often present a long or feature-heavy backlog, a value debate between stakeholders or a poorly written item, and ask which action best focuses the work on outcomes and the Product Goal.
-
Outcome or output
A success measure is described, and you decide whether it tracks outcome or output and how to improve it.
-
Economics of ordering
Several items differ in value, cost and urgency, and you apply cost of delay or similar reasoning to order them.
-
Item quality
A backlog item lacks purpose or value, and you choose the rewrite that states the desired outcome.
A Product Owner's backlog has 400 items, and leadership measures the team by items closed per Sprint. Customer retention, the stated Product Goal, has not moved in six months. The best response is to measure retention-related outcomes, remove or archive items that do not serve the goal, and order the remaining work by its expected effect on retention rather than by request date.
Learning objectives 8
Official learning objectives from the Scrum Alliance outline, in outline order.
5.1 Describe the relationship between outcome and outputResults versus things delivered.
- What it means
- Output is what the team produces, such as features, items and releases. Outcome is the change that output causes, such as customers completing tasks faster or more users renewing. Impact is the longer-term business effect.
- What to understand
- Output is a means to an outcome, not the goal itself. The same outcome may be reached with more or less output, so smaller, targeted changes are often better. Product Owners plan and measure in outcome terms and treat features as bets that might produce them.
- How it shows up
- Practice items describe a metric and ask whether it measures outcome or output.
- Common confusion
- Treating velocity or number of features shipped as a measure of product success.
5.2 List at least three actions the product owner could take to maximize outcomes and impact while minimizing outputsDoing less to achieve more.
- What it means
- This objective asks for concrete moves that raise outcomes while reducing the amount of work. Examples include removing low-value backlog items, slicing work smaller, testing before building, reusing existing features, retiring unused functionality and setting a clear Product Goal to say no against.
- What to understand
- Every item built carries cost to build, maintain and support. Fewer, better-targeted items free the team to focus. Saying no is part of the Product Owner role, and a clear goal makes refusals easier to explain to stakeholders.
- How it shows up
- A scenario describes an overloaded backlog and asks which action best increases outcome.
- Common confusion
- Assuming more output always increases value.
5.3 Define at least three terms related to product economicsFinancial language for product decisions.
- What it means
- Product economics terms help explain value in business language. Common examples are return on investment, cost of delay, total cost of ownership, opportunity cost, lifetime value, profit and loss, and capital versus operating expense.
- What to understand
- Cost of delay shows how much value is lost by waiting and supports ordering urgent items earlier. Total cost of ownership reminds teams that maintenance often exceeds build cost. Opportunity cost captures what is given up by choosing one item over another. Using these terms makes backlog choices easier to defend.
- How it shows up
- Prompts give a definition and ask which product economics term it describes.
- Common confusion
- Mixing up cost of delay with the cost of building the item.
5.4 Describe value from the perspective of at least three different stakeholder groupsValue means different things to different people.
- What it means
- Value is not one number. Customers may value saved money, users saved time or less frustration, the business revenue or reduced risk, operations stability, and the Developers a maintainable codebase.
- What to understand
- A Product Owner balances these views and makes the trade-offs visible. Some items create value for one group at a cost to another, such as a sales feature that adds support load. Describing value per group helps stakeholders see why an item is ordered where it is.
- How it shows up
- Scenarios ask how an item creates or affects value for different groups.
- Common confusion
- Assuming value always means revenue.
5.5 List at least three techniques to measure valueTurning value into evidence.
- What it means
- Measuring value means choosing signals that show whether outcomes are improving. Techniques include product analytics, customer satisfaction or Net Promoter Score, retention and churn rates, task completion time, revenue per customer, support ticket volume and Evidence-Based Management style measures.
- What to understand
- Good measures are leading where possible, tied to the Product Goal and checked regularly. Vanity metrics such as page views can rise without real value. Combining a behavior measure with a feedback measure gives a fuller picture.
- How it shows up
- Practice items ask which metric would best show that a change delivered value.
- Common confusion
- Relying on vanity metrics that rise without any real benefit.
5.6 Create a product backlog that supports the achievement of a product goalA backlog shaped by the goal.
- What it means
- This objective is a hands-on exercise: build a Product Backlog whose items, ordering and level of detail clearly serve one Product Goal. The goal sits within the backlog as its commitment.
- What to understand
- Items that do not contribute to the current Product Goal should be questioned, deferred or removed. Items near the top are small and clear; those further down stay coarse until needed. The backlog is emergent and changes as the team learns.
- How it shows up
- A backlog sample is shown, and you identify items that do not serve the stated Product Goal.
- Common confusion
- Keeping every requested item in the backlog regardless of the goal.
5.7 Create at least one product backlog item that includes a description of desired outcome and valueItems that explain why.
- What it means
- A good Product Backlog Item says what change it should produce and for whom, not just what to build. Formats include user stories with a clear so that clause, job stories or hypothesis statements with success measures.
- What to understand
- Stating the outcome lets Developers suggest better solutions and helps everyone judge when the item is valuable enough. Acceptance criteria describe conditions of completion, while the outcome describes why it matters. Both help the team and stakeholders inspect results.
- How it shows up
- You may be asked which item wording best expresses desired outcome and value.
- Common confusion
- Writing items as technical tasks with no purpose or beneficiary stated.
5.8 Practice at least one approach to refining the product backlogKeeping the backlog ready.
- What it means
- Refinement is the ongoing activity of breaking down, clarifying, estimating and ordering Product Backlog Items. Approaches include regular refinement sessions, story mapping, splitting workshops, three amigos conversations and estimation techniques such as Planning Poker.
- What to understand
- The Developers who will do the work are responsible for sizing, while the Product Owner clarifies purpose and order. Refinement is not a Scrum event and has no fixed timebox, but keeping a few Sprints of ready work helps Sprint Planning. Too much early detail is waste.
- How it shows up
- Scenarios ask who sizes items or how to prepare work before Sprint Planning.
- Common confusion
- Believing the Product Owner estimates items for the Developers.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Outcome
Change in behavior or results.
- Remember
- The real measure of success.
- Tested as
- Objective 5.1.
- Trap
- Equating it with output.
-
Output
Features and items delivered.
- Remember
- A means, not the goal.
- Tested as
- Objective 5.1.
- Trap
- Measuring success by volume.
-
Cost of delay
Value lost by waiting.
- Remember
- Supports ordering urgent value first.
- Tested as
- Product economics term.
- Trap
- Confusing with build cost.
-
Total cost of ownership
Full cost over a feature's life.
- Remember
- Maintenance often exceeds build.
- Tested as
- Product economics term.
- Trap
- Ignoring upkeep when adding features.
-
Opportunity cost
Value forgone by choosing one option.
- Remember
- Every yes is a no elsewhere.
- Tested as
- Product economics term.
- Trap
- Ignoring alternatives.
-
Vanity metric
Measure that rises without real value.
- Remember
- Prefer outcome-linked measures.
- Tested as
- Measuring value.
- Trap
- Reporting page views as success.
-
Product Backlog Item
Unit of work in the backlog.
- Remember
- Should state outcome and value.
- Tested as
- Objective 5.7.
- Trap
- Writing it as a technical task.
-
Refinement
Ongoing clarifying, splitting and sizing.
- Remember
- Not a Scrum event; Developers size.
- Tested as
- Objective 5.8.
- Trap
- Product Owner sizing items alone.
-
Emergent backlog
Backlog changes as learning grows.
- Remember
- Detail rises toward the top.
- Tested as
- Supports 5.6.
- Trap
- Fully detailing every item upfront.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Output vs. outcome vs. impact
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Output | What the team delivers | Easy to count | Using it as success |
| Outcome | Change in user behavior | Shows whether output worked | Measuring too late |
| Impact | Long-term business effect | Broadest, slowest signal | Attributing it to one feature |
Product economics terms
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Return on investment | Gain relative to cost | Looks at overall payoff | Ignoring timing |
| Cost of delay | Value lost per unit of time waiting | Focuses on urgency | Confusing with build cost |
| Total cost of ownership | Build plus run and maintain | Covers full lifetime | Counting only build cost |
| Opportunity cost | Value of the next best option | Captures trade-offs | Ignoring alternatives |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Velocity as value
- What candidates pick
- Report rising velocity as proof the product is succeeding.
- Why it looks right
- Velocity is easy to measure.
- Why it's wrong
- Velocity measures output for planning; it says nothing about whether customers or the business are better off.
Clue to watch for Success is described in items or points delivered.
-
Keep everything
- What candidates pick
- Retain every stakeholder request in the backlog.
- Why it looks right
- It avoids saying no.
- Why it's wrong
- Items that do not serve the Product Goal add noise and cost; removing them focuses the team.
Clue to watch for The backlog has hundreds of old items.
-
Cost of delay is build cost
- What candidates pick
- Use effort estimates as cost of delay.
- Why it looks right
- Both involve cost.
- Why it's wrong
- Cost of delay is value lost by waiting, separate from the effort needed to build the item.
Clue to watch for A definition mentions value lost over time.
-
Revenue only
- What candidates pick
- Define value solely as revenue.
- Why it looks right
- Revenue is visible and important.
- Why it's wrong
- Value differs across customers, users, operations and the team, and some value reduces risk or cost instead.
Clue to watch for The question names several stakeholder groups.
-
Product Owner sizes
- What candidates pick
- Have the Product Owner estimate items to speed up planning.
- Why it looks right
- The Product Owner knows the items best.
- Why it's wrong
- The Developers doing the work are responsible for sizing; the Product Owner clarifies purpose and order.
Clue to watch for The question asks who estimates.
-
Refinement as a timeboxed event
- What candidates pick
- Treat refinement as a fixed Scrum event with a set timebox.
- Why it looks right
- Teams often schedule it like one.
- Why it's wrong
- Refinement is an ongoing activity, not one of the Scrum events, and teams decide how to carry it out.
Clue to watch for Refinement is described as a required meeting.
Answer framework
Use these steps when deciding what goes in the Product Backlog and in what order.
- Start from the current Product Goal and the outcome it describes, not from the list of requests or features.
- Check each item for a stated outcome and beneficiary, and rewrite or remove items that cannot show how they help.
- Use product economics such as cost of delay and total cost of ownership to compare items that compete for the same capacity.
- Consider value for customers, users, the business and the team, and make any trade-offs between them visible.
- Measure outcomes with signals tied to the goal, and refine with the Developers so that the top items stay small, clear and sized.
Practice question
Want more like this? The CSPO practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
This is the largest category, so allow six to nine hours. Begin with outcome versus output: take your team's current success measures and label each one. Then learn four product economics terms well enough to explain them to a finance colleague with an example from your own product, especially cost of delay, which trainers often use in ordering exercises.
Next, export or sketch your backlog, write the Product Goal at the top, and mark each item as serving the goal, unclear or unrelated. Rewrite three unclear items so they state an outcome and who benefits. During the course, expect to build a small backlog from scratch and run a refinement exercise, so practise splitting and Planning Poker beforehand if they are new to you. Afterwards, choose two value measures for your product and review them each Sprint. The practice knowledge checks here are optional confidence builders; certification depends only on finishing the course.
FAQ
How much of the CSPO does Working with the Product Backlog cover?
Working with the Product Backlog has the most learning objectives of any CSPO category, 8 of 28. Scrum Alliance does not weight categories, and there is no exam that scores them.
What is the difference between outcome and output?
Output is what the team delivers, such as features. Outcome is the change that results, such as users completing tasks faster or staying longer.
What is cost of delay?
It is the value lost for each period an item is not delivered. Items with high cost of delay and modest size often deserve a higher place in the backlog.
Who estimates Product Backlog Items?
The Developers who will do the work size the items. The Product Owner explains purpose and value and may influence choices by clarifying trade-offs.
Is refinement a Scrum event?
No. Refinement is an ongoing activity. Teams decide how and when to do it, often in regular sessions that keep a few Sprints of work ready.
How should a backlog item describe value?
It should say what change the item should produce and for whom, for example with a user story's so that clause or a hypothesis with a success measure.
Other Agile & Scrum certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
You have covered outcomes, product economics, value, measurement and refinement. Take a short knowledge check to see whether you can make outcome-focused backlog decisions.