Home / agile-scrum / Certified Scrum Product Owner (CSPO) / Cheat Sheet
Certified Scrum Product Owner (CSPO)

CSPO Cheat Sheet

CSPO Rewards Owning Outcomes and Backlog Order — Not Passing a Test

There is no CSPO exam: Scrum Alliance awards it after a 16-hour live course with a certified trainer. Use the 28 learning objectives to check you can think in outcomes, not feature lists.

Check Your Readiness →
Among the harder certs
Avg: Not published by Scrum Alliance (no exam is held)
Pass: 750 / 1000
Most candidates understand Certified Scrum Product Owner (CSPO) concepts — and still fail. This exam tests how you apply knowledge under pressure.

CSPO Learning Objectives Map (five categories, 28 objectives)

Categories follow the CSPO Learning Objectives (updated January 2022). Trainers cover them through class exercises and discussion rather than a graded test. Use the self-checks here the way a trainer would: short workplace situations asking which Product Owner behaviour fits the objectives and the Scrum Guide.

  1. 01
    Product Owner Core Competencies (7 objectives, no exam weight) — single accountable owner, backlog authority, stakeholder transparency, multi-team setups
  2. 02
    Goal Setting and Planning (6 objectives, no exam weight) — vision vs. Product Goal vs. Sprint Goal, forecasts, release planning, slicing
  3. 03
    Understanding Customers and Users (5 objectives, no exam weight) — continuous discovery, segmentation, conflicting needs, direct Developer contact
  4. 04
    Validating Product Assumptions (2 objectives, no exam weight) — riskiest assumption first; compare tests by cost and quality of learning
  5. 05
    Working with the Product Backlog (8 objectives, no exam weight) — outcome over output, product economics, measuring value, refinement

Wrong instinct vs correct approach

A sponsor demands every listed feature by a fixed launch date and wants a firm commitment
✕ Wrong instinct

Promise all scope by that date to keep the sponsor happy

✓ Correct approach

Forecast from measured throughput and show a range with its assumptions. When the date is fixed, scope is the lever, so order by value and release the most valuable usable Increments first.

Developers misread backlog items because the Product Owner relays all user feedback in writing
✕ Wrong instinct

Write longer, more detailed backlog items for the Developers

✓ Correct approach

Connect Developers directly with users through interviews, observation or usability sessions. Direct contact gives context, catches misunderstandings early and improves solution ideas; the Product Owner is not meant to be a gatekeeper.

A new feature is proposed as database work first, then the API, then the screens
✕ Wrong instinct

Accept the layer-by-layer plan because it matches the architecture

✓ Correct approach

Horizontal layers give users nothing usable until the end. Slice vertically, or use a story map, to find the thinnest end-to-end piece a real user can try, then release it as soon as it adds value.

Two customer segments ask for opposite behaviour in the same workflow
✕ Wrong instinct

Give each segment half of what it asked for

✓ Correct approach

Split-the-difference solutions often satisfy nobody. Weigh each need against the Product Goal, the expected outcome and the evidence behind it, then decide transparently and explain the trade-off to both groups.

Know these cold

  • ▸ No CSPO exam — 6 hours of live training with a Scrum Alliance trainer earns the credential
  • ▸ Renewal is 20 SEUs plus a fee every two years; 30 SEUs is the A-CSPO figure
  • ▸ Product Owner may delegate backlog work but always remains accountable for it
  • ▸ One product means one Product Backlog and one Product Owner, however many teams build it
  • ▸ Vision rarely changes; one Product Goal at a time; Sprint Goal is crafted by the whole team
  • ▸ Developers size backlog items; the Product Owner clarifies purpose and decides order
  • ▸ Cost of delay is value lost by waiting, not the effort needed to build
  • ▸ Customers choose or pay; users work with the product daily; they can want different things
  • ▸ Test the riskiest assumption first; measured behaviour beats stated intent as evidence
  • ▸ Release burn-up shows scope growth; roadmaps show direction, never commitments

Can you answer these without checking your notes?

In this scenario: "A sponsor demands every listed feature by a fixed launch date and wants a firm commitment" — what should you do first?
Forecast from measured throughput and show a range with its assumptions. When the date is fixed, scope is the lever, so order by value and release the most valuable usable Increments first.
In this scenario: "Developers misread backlog items because the Product Owner relays all user feedback in writing" — what should you do first?
Connect Developers directly with users through interviews, observation or usability sessions. Direct contact gives context, catches misunderstandings early and improves solution ideas; the Product Owner is not meant to be a gatekeeper.
In this scenario: "A new feature is proposed as database work first, then the API, then the screens" — what should you do first?
Horizontal layers give users nothing usable until the end. Slice vertically, or use a story map, to find the thinnest end-to-end piece a real user can try, then release it as soon as it adds value.

Common Exam Mistakes — What candidates get wrong

Letting a steering group vote on Product Backlog order each Sprint

The Product Owner is one person, not a committee. Business unit heads give input, but ordering decisions stay with the Product Owner, who explains the reasoning openly. Voting diffuses accountability and slows every decision about value.

Writing the Product Goal as a bulleted list of features

A Product Goal states an outcome the team can test, such as reducing churn; features are options for reaching it and live in the backlog. The vision is longer-range and rarely changes, while each Product Goal is met or abandoned.

Arriving at Sprint Planning with a finished, non-negotiable Sprint Goal

The whole Scrum Team crafts the Sprint Goal during Sprint Planning. The Product Owner proposes how the product could increase its value and usefulness, but Developers shape what is achievable and decide how much work they select.

Reporting features shipped or velocity as proof of product success

Velocity and feature counts measure output. CSPO objectives centre on outcome, a change in customer behaviour or business results, and impact. Thirty features shipped while churn stays flat is a signal to rethink the backlog, not celebrate.

Building the whole feature to find out whether anyone wants it

A full build is the costliest experiment. Name the riskiest assumption, then compare cheaper tests by quality of learning: interviews capture opinion, fake door and landing pages measure behaviour, and A/B tests need a live product with traffic.

Resources to help you pass Certified Scrum Product Owner on your first attempt

No test stands between you and CSPO. Check whether you already think like an outcome-driven Product Owner.