• 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.
• 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.

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 the 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 criteria 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.
• 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.