1

SCRUM ALLIANCE ®

CERTIFIED SCRUM PRODUCT OWNER ®

Learning Objectives
March 2017
by the Scrum Alliance CSPO® and CSP® Learning Objectives Committees

INTRODUCTION
Purpose
This document describes the Learning Objectives (LOs) that must be covered in a Certified Scrum Product
Owner (CSPO) course. These Learning Objectives take the following into consideration:
• Every implementation of Scrum is different.
• Teams and organizations apply Scrum within their context, but the fundamental framework always
remains the same.

The Learning Objectives for this course are based on:

● Scrum Guide, http://scrumguides.org
● Agile Manifesto, 4 values and 12 principles, http://www.agilemanifesto.org

Scope
Scrum Alliance has adopted The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game,
coauthored and updated (most recently in 2016) by the co-creators of the Scrum framework, as the guiding
curriculum for this course. CSPO® candidates are expected to build a body of knowledge of the Scrum
framework, including its roles, events, and artifacts. Incorporating Scrum principles and practices takes
diligence, patience, and a commitment to continuous improvement. Scrum is a framework, not
a prescriptive methodology.

Participants in a CSPO course should expect that each Learning Objective identified in this document will be
covered in a CSPO course. The CSPO Learning Objectives fall into the following categories:
1. Understanding the Role of the Product Owner
2. Describing Purpose and Strategy Abbreviations
3. Understanding Customers and Users LO — Learning Objective
4. Testing Product Assumptions PO — Product Owner
5. Working with the Product Backlog

Individual trainers (CSTs) or coaches (CECs) may choose to teach ancillary topics. Examples might include:
Lean Start-up, Design Thinking, Agile Leadership, Domain-Specific Approaches, Agile Contracts, etc. Ancillary
topics presented in a CSPO course must be clearly indicated as such.

scrumalliance.org
 2

LEARNING OBJECTIVES
A note about examples used in the following Learning Objectives:
Several Learning Objectives include a list of examples. The examples are used to clarify the intent of the
objective. Individual trainers or coaches can use the provided examples, their own examples that still meet the
objective, or a mix of both. Examples do not imply that they are the only options, nor that they constitute an
exhaustive list.

A note about Bloom’s Taxonomy:

While some Learning Objectives appear to tell the trainer how to teach, that is not the intent. Bloom’s-style
Learning Objectives describe what the learner can do upon completing the class. Rather than include that text
in each Learning Objective, please mentally append the following phrase to each objective:

“Upon successful completion of the CSPO course, the learner will be able to …”

1. Understanding the Role of the Product Owner

Fundamentals of the Product Owner Role
1.1. … describe the responsibilities of the Product Owner role and the benefits of Scrum Team
collaboration.
1.2. … report that the Product Owner helps the organization realize value through delivering product
solutions that delight customers and users within the constraints of technical feasibility.
1.3. … describe the Product Owner’s role in the various Scrum events.
1.4. … list at least three personal qualities of a Product Owner that support effective delivery and
validation of product ideas. For example: emotional intelligence, collaborative skills, motivating
teams, knowledge of Scrum, ability to work and empathize with customers, ability to communicate
difficult decisions at all levels, ability to work within an organization to remove impediments,
ability to say no, business skills, knowledge of the complete product life cycle, ability to apply the
80/20 rule, conflict management, negotiation skills, ability to influence, ability to make decisions,
domain expertise.
1.5. … identify the impact on a Scrum Team and organization of at least three anti-patterns that might
exist for Product Owners and report on one. For example: The Product Owner is viewed as simply
an order taker; the Product Owner says, “It’s all important,” focusing only on strategy and handing
details off to the Development Team; leaving everything ambiguous, letting the team figure it out
with no input; telling the team how to do their job.
1.6. … discuss at least three types of organizational contexts that affect the approach to the Product
Owner role and report on one. For example: A Product Owner has complete ownership of target
customer, problem, and solution; a Product Owner owns the delivery of someone else’s idea or
initiative; a Product Owner delivers a shared service to other teams in the organization; a Product
Owner works on short-term projects that they own the outcome for, etc.

scrumalliance.org
 3

1.7. … explain why Scrum as a framework works for product development and how the Scrum Team
delivers product increments. For example: Discover and evaluate a real-world product idea where
the output delivered a successful outcome and used feedback loops to inspect and adapt plans for
further value delivery; describe how Scrum reduces risk through inspection and adaptation over
short timeframes; describe how Scrum creates an environment where imperfect knowledge and/or
decisions are acceptable since Scrum enables error corrections.

Working with Stakeholders

1.8 … use at least one technique to provide transparency to stakeholders on goals and progress. For
example: release burn-up chart, roadmap, sprint reviews, etc.
1.9 … list at least three different decision-making approaches a Product Owner might use,
depending on their context. For example: Product Owner decides and informs the team,
Product Owner consults the Development Team and/or stakeholders and then decides, Product
Owner delegates a decision, etc.
1.10 … define a facilitator and discuss at least two situations where the Product Owner might act as
a neutral facilitator and when they might use a different engagement approach.
1.11 … list one technique a Product Owner could use when engaging with stakeholders to gather
information or insights (e.g., affinity grouping, dot voting, fist of five, open-ended questions, etc.).

Working with the Development Team

1.12 … describe how the Product Owner collaborates with the Development Team on activities such as
defining done and backlog creation, refinement, and ordering.

Product Ownership with Multiple Teams

1.13 … list at least three techniques for visualizing, managing, or reducing dependencies between
teams. For example: Coordinate with other Product Owners, redefine product backlog items to
remove dependencies, ensure product backlogs are visibly shared between Product Owners and
Scrum Teams.

2. Describing Purpose and Strategy

Product Strategy
2.1 … define the terms purpose, vision, mission, strategy, and tactics in relation to the work. (Note for
trainers/coaches: These terms are debated among experts in the business community, so the goal
is not to “get the right answer” but to have the discussion and agree how the terms might be used
on the learner’s team.)
2.2 … communicate the purpose of a product idea by describing the problem being solved, who is
most affected by the problem, how the team’s efforts will improve the situation, and how that
solution’s effectiveness will be evaluated.
2.3 … identify at least two approaches to identify purpose or define strategy. For example: co-creating,
collaborating.
2.4 … explain how strategy is impacted from outside the Scrum Team. For example: alignment with other
parts of the business, hiring, channel partners, cost structure, metrics, etc.

scrumalliance.org
 4

Roadmaps and Release Planning

2.5 … describe at least three different strategies for the incremental delivery of a product. For example:
opportunistic, multi sprint releases, fixed date or fixed scope, release each sprint, continuous
delivery (in sprint), etc.
2.6 … explain how to create a prioritized product roadmap with stakeholders.
2.7 … describe a solution or feature as progressively smaller items that may be completed in a sprint.

3. Understanding Customers and Users

Customer Research and Product Discovery
3.1 … compare and contrast the needs of three key groups: users who use a product, customers who
buy a product, and any additional stakeholders who benefit from the product’s delivery and use.
3.2 … illustrate at least one approach for segmenting customers and users. For example: customer
types, geography, regulatory bodies.
3.3 … describe a strategy for product prioritization by focusing on specific user/customer types
for discovery and delivery versus a strategy of focusing on multiple users and customers
without focus.
3.4 … describe at least three benefits and apply at least one technique to connect teams directly to
customers and users to build deeper understanding and empathy. For example: job shadowing,
customer interviews, customer observation, collaborative customer games, usability testing, or
simulating customer experience.
3.5 … use one technique to describe users and customers, their jobs, activities, pains, and gains.
For example: empathy maps or personas.
3.6 … describe at least three techniques to generate new product and feature ideas, and practice one.
For example: design studio, brainstorming, collaborative customer games, etc.
3.7 … describe at least three aspects of product discovery and identify how each contributes to
successful product outcomes. For example: user research, customer experience design,
interaction design, usability engineering, visual design.
3.8 … list at least three techniques to connect teams directly to customers and users to build deeper
understanding and empathy (e.g., job shadowing, customer interviews, customer observation,
collaborative customer games, usability testing, or simulating customer experience).

4. Testing Product Assumptions

4.1 … explain how the sprint review is an effective inspect-and-adapt step to review the product
increment built, user insights, experiments, options, and product opportunities.
4.2 … recognize the difference between an assumption and a hypothesis.
4.3 … describe how Scrum supports testing product assumptions by using each sprint to experiment and
learn about the product, specific process adaptations, and the plan followed.
4.4 … discuss opportunities to test assumptions during product discovery, product development, and
delivery (i.e., find the problem, find the solution, produce the solution, validate).
4.5 … list at least three reasons why a Product Owner performs discovery and validation work. For
example: the low use rate of delivered features, the high failure rate of start-ups, the impact of
cognitive bias on decision making, complexity science, pace of change, risk reduction, etc.

scrumalliance.org
 5

4.6 … describe at least one approach to choosing which assumption should be tested first. For
example: highest business risk, most opportunity for learning, highest technical risk, etc.
4.7 … list at least three approaches to testing assumptions by their cost and the quality of learning.
For example: building a potentially releasable product, problem and solution interviews,
ethnographic research, direct user observation, A/B tests, concierge/Wizard of Oz MVPs, paper
prototypes, customer games, functional prototypes, etc.

5. Working with the Product Backlog

Differentiating Outcome and Output
5.1 … describe the relationship between outcome and output and the Product Owner’s responsibility to
maximize value. For example: Output is a measure of what was built, outcome is how that output
impacts users and customers; the resulting business value that this provides.
5.2 … describe at least three attributes of a product backlog item that helps assess maximizing
outcome and impact. For example: who needs it, why do they need it, how to test it, why it is
valuable, how long it might take to build, etc.

Defining Value
5.3 … define what value is (and is not). For example: modeled or assumed value, actual value to
customer, ROI, maximizing learning, risk/de-risk, acquiring new customers.
5.4 … list at least two techniques to measure value. For example: usage metrics, NPS, customer and
user interviews, social media sentiment, direct observation, ROI, profitability of the product,
inbound customer feedback, etc.
5.5 … describe value from the perspective of at least three different stakeholder groups. For example:
users, business stakeholders, or Development Team members.

Ordering Items
5.6 … describe at least three criterion to consider for ordering the product backlog and apply one. For
example: strategic alignment, business value, user value, learning value, time to market, estimated
cost of building, risk, etc.
5.7 … apply at least one technique to order the product backlog. For example: Kano attributes, validated
learning, walking skeleton, dot voting, Pareto (80/20 rule), bubble sort, lifeboat strategy,
collaborative customer games.

Creating and Refining Items

5.8 … identify at least three sources of product backlog items. For example: stakeholder groups,
regulatory requirements, learning from validation, defects, technical concerns, etc.
5.9 … create product backlog items that reflect impact and desired outcome. For example: user stories
and acceptance criteria, use cases, hypotheses, BDD, system qualities, spikes.
5.10 … describe at least one approach to accomplishing product backlog refinement. For example:
weekly meetings with the Scrum Team, ongoing ad hoc refinement as needed, Product Owner
does the majority of product backlog refinement.

scrumalliance.org
 6

5.11 … recognize the pros and cons of a “just-in-time” approach for product backlog refinement vs. an
“all-at-once” approach.
5.12 … describe at least three tools to communicate, clarify, and refine the Scrum Team’s understanding
of product backlog items and implement two tools. For example: roadmaps, user story map,
wireframe, use cases, flowcharts, prototypes, estimates, or acceptance criteria.
5.13 … explain at least two approaches to identify small, valuable, releasable subsets of a big idea or
feature. For example: minimum viable product release, release to learn, minimum marketable
features, valuable vertical slices, etc.
5.14 … describe one benefit of decomposing larger, valuable product backlog items into smaller,
reprioritized items. For example: 80/20 rule, YAGNI.
5.15 … refine larger product backlog items into smaller ones that are “Ready” to be built by the
Development Team in a sprint.

scrumalliance.org
 7

PROGRAM TEAMS
Certification Updates:
Path to CSP and Progressive Courses
• Karim Harbott
• Erika Massie
• Carlton Nettleton
• Lisa Reeder
• Jason Tanner
• Andreas Schliep

Scrum Foundations and CSPO, CSPO Level 2, and CSP-CSPO

• Peter Green
• Catherine Louis
• Jeff Patton
• Aaron Sanders

This group supported by Scrum Alliance staff Lisa Reeder and Erika Jones Massie.

scrumalliance.org