PSPO I — Scrum.org Professional Scrum Product Owner I Scenario Practice Guide

This guide is for candidates preparing for the Scrum.org Professional Scrum Product Owner I, PSPO I, exam. It is independent exam-preparation guidance and is not affiliated with Scrum.org.

Scenario questions in PSPO I reward disciplined reading. The best answer is often not the answer that feels most active, forceful, or manager-like. It is the answer that best fits Scrum accountabilities, empiricism, transparency, product value, and the Product Owner’s role in maximizing value.

Use this page as a final-review method for slowing down, finding the actual decision point, and choosing the most defensible answer from the facts provided.

Think Like a Product Owner, Not a Project Manager

PSPO I scenarios often describe product decisions, stakeholder pressure, unclear Product Backlog items, changing market needs, release concerns, Sprint issues, or conflicts about value. Your job is to identify what Scrum says should happen next.

A strong Product Owner answer usually supports these ideas:

• Maximize the value of the product resulting from the Scrum Team’s work.
• Own Product Backlog management and ordering.
• Make Product Backlog items transparent, understandable, and ordered.
• Collaborate with stakeholders, Developers, and the Scrum Master.
• Use evidence, inspection, and adaptation rather than prediction-only planning.
• Respect the Developers’ accountability for creating the Increment and managing the Sprint Backlog.
• Respect Scrum events, artifacts, and commitments.
• Avoid acting as a command-and-control project manager.

When reading a scenario, keep asking: What is the Product Owner accountable for here, and what should be made transparent before deciding?

Use a Five-Step Reading Method

1. Identify the role in the scenario

Start by asking who is being asked to act.

Common role signals:

• Product Owner: product value, Product Backlog ordering, stakeholder input, Product Goal, release decisions, Product Backlog transparency.
• Developers: Sprint Backlog, technical implementation, creating the Increment, estimates, plan for the Sprint.
• Scrum Master: Scrum effectiveness, coaching, removing impediments, helping people understand Scrum.
• Stakeholders: needs, feedback, expectations, business goals, market input, regulatory or customer concerns.

The PSPO I decision often turns on whether the Product Owner should decide, collaborate, clarify, or allow another Scrum accountability to do its work.

For example:

• If the question is about ordering Product Backlog items, look to the Product Owner.
• If the question is about how Developers perform the work during the Sprint, look to the Developers.
• If the question is about coaching someone on Scrum, look to the Scrum Master.
• If the question is about market value or stakeholder priorities, the Product Owner listens, analyzes, and decides.

2. Determine the Scrum context

PSPO I is Scrum-focused, so identify where in Scrum the scenario takes place.

Look for context clues:

• Before Sprint Planning: Product Backlog refinement, ordering, Product Goal alignment, stakeholder input.
• During Sprint Planning: selecting work, crafting or understanding the Sprint Goal, ensuring the selected work is clear enough.
• During the Sprint: changes, stakeholder requests, Sprint Goal impact, collaboration with Developers.
• At Sprint Review: inspecting the Increment, discussing progress toward the Product Goal, adapting the Product Backlog.
• At Sprint Retrospective: improving how the Scrum Team works.
• During refinement: improving clarity, splitting Product Backlog items, estimating, ordering, and understanding.

Do not treat all scenarios as general project-management problems. Scrum has specific accountabilities and events. The best answer should fit the context.

3. Find the actual problem

Separate the surface story from the real decision point.

A scenario may mention many details, but the core problem is usually one of these:

• Value problem: Which work should be ordered first?
• Transparency problem: The Product Backlog, Increment, progress, or stakeholder expectations are unclear.
• Stakeholder alignment problem: Different people want different outcomes.
• Sprint Goal problem: New information may affect the current Sprint Goal.
• Definition of Done problem: There is uncertainty about whether work is releasable.
• Release decision problem: The Increment is Done, but the Product Owner must decide whether releasing is valuable.
• Accountability problem: Someone is trying to make a decision that belongs to another Scrum accountability.
• Empiricism problem: People are trying to decide without inspection, evidence, or transparency.

Once you name the real problem, weak answer choices become easier to reject.

4. Decide whether action, communication, or analysis comes first

In PSPO I scenarios, the first move is often not “tell everyone what to do.” A defensible Product Owner response usually starts with the correct Scrum behavior.

Use this sequence:

1. Make the situation transparent.

   • What is known?
   • What is uncertain?
   • What impact does it have on value, the Product Goal, or the Sprint Goal?

2. Collaborate with the right people.

   • Developers for feasibility, effort, technical options, and Sprint impact.
   • Stakeholders for value, feedback, and business consequences.
   • Scrum Master for Scrum coaching and impediment handling.

3. Inspect evidence.

   • Product performance, stakeholder feedback, market data, Done Increment, Product Backlog order, progress toward goals.

4. Adapt the Product Backlog or plan where appropriate.

   • Reorder Product Backlog items.
   • Clarify items.
   • Add, remove, or split items.
   • Adjust forecasts based on evidence.

5. Decide within the Product Owner accountability.

   • The Product Owner decides Product Backlog order.
   • The Product Owner may decide whether to release a Done Increment.
   • The Product Owner does not dictate how Developers build the Increment.

5. Choose the best next step

The best answer should be the next useful Scrum action, not the most dramatic action.

Ask:

• Does this answer preserve Scrum accountabilities?
• Does it improve transparency?
• Does it support inspection and adaptation?
• Does it help maximize value?
• Does it respect the Sprint Goal?
• Does it avoid unnecessary escalation or command-and-control behavior?
• Is it something the named role is actually accountable for?

If two answers seem plausible, prefer the one that is more consistent with Scrum principles and the Product Owner accountability.

Identify Product Owner Decision Points

The Product Owner is accountable for maximizing value and for effective Product Backlog management. Scenario answers often depend on recognizing when the Product Owner should decide and when the Product Owner should collaborate.

Product Backlog ordering

If the scenario asks what should be worked on next, the Product Owner is responsible for ordering the Product Backlog.

Good reasoning:

• Consider value, risk, learning, dependencies, urgency, and stakeholder needs.
• Use evidence and stakeholder input.
• Keep the Product Backlog transparent.
• Do not let a committee replace the Product Owner’s accountability.

The Product Owner can and should listen to others, but remains accountable for ordering.

Product Backlog clarity

If Developers do not understand an item, the Product Owner should collaborate to improve clarity.

Good reasoning:

• Product Backlog items should be transparent enough for their place in the Product Backlog.
• Items selected for a Sprint need enough understanding to support Sprint Planning.
• Refinement is ongoing and collaborative.
• The Product Owner does not need to write every detail alone.

The defensible answer usually involves collaboration, clarification, splitting, or refinement.

Stakeholder disagreement

Stakeholders may disagree about priority, scope, release timing, or value. The Product Owner should listen, make trade-offs transparent, and decide based on value.

Good reasoning:

• Stakeholder input matters.
• The Product Owner is not a passive note-taker.
• The Product Owner does not simply accept the loudest stakeholder’s request.
• The Product Owner should use evidence and product goals to order work.

Release decisions

A Done Increment may be releasable, but release is a business decision. The Product Owner often decides whether and when releasing creates value.

Good reasoning:

• “Done” means usable and potentially releasable.
• Release does not have to wait for Sprint Review.
• A Sprint Review is for inspection and adaptation, not a phase-gate approval board.
• Releasing should be based on value, risk, market timing, and product strategy.

Read Sprint Scenarios Carefully

Many PSPO I scenarios involve requests during a Sprint. Do not answer as though the Product Owner can simply inject work into the Sprint Backlog or redirect Developers.

When a new request appears during the Sprint

Ask:

• Does the request threaten or support the Sprint Goal?
• Is the work already in the Sprint Backlog?
• Is the request urgent enough to discuss immediately?
• What do the Developers say about impact?
• Should the Product Backlog be reordered for future work instead?

A strong answer often involves the Product Owner discussing the request with Developers and considering the Sprint Goal.

The Product Owner may clarify, negotiate, and collaborate, but should not unilaterally force new work into the Sprint.

When the Sprint Goal becomes obsolete

If the Sprint Goal no longer makes sense, Scrum allows the Product Owner to cancel the Sprint. This is a significant decision, not a routine response to every change.

Reason through it carefully:

• Has the Sprint Goal truly become obsolete?
• Is there a better response through collaboration or Product Backlog adaptation?
• Is cancellation the only sensible option, or is it an overreaction?

For PSPO I, treat Sprint cancellation as possible but exceptional.

When Developers ask for changes to scope

Developers may learn during the Sprint that selected work is larger, smaller, or different than expected. The Product Owner should collaborate with them, especially if scope trade-offs affect the Sprint Goal or value.

Good reasoning:

• Developers manage the Sprint Backlog.
• The Product Owner can help clarify value and negotiate scope.
• The Sprint Goal provides focus.
• Transparency is better than pretending the original plan is fixed.

Determine Whether the Question Is About Predictive Thinking or Empirical Thinking

Product Owner scenarios often include forecasts, deadlines, commitments, roadmaps, or stakeholder expectations. The exam context is Scrum, so reason empirically.

Predictive thinking says:

• Plan everything in advance.
• Lock scope, date, and cost.
• Treat deviation as failure.
• Escalate to enforce the plan.

Empirical Scrum thinking says:

• Make work and progress transparent.
• Inspect real results frequently.
• Adapt the Product Backlog based on learning.
• Forecast using evidence.
• Optimize value, not just output.

When a scenario pressures the Product Owner to guarantee all scope by a date, the stronger answer is usually about transparency, ordering, forecasting, trade-offs, and stakeholder collaboration rather than unrealistic certainty.

Separate Facts from Distractors

A scenario may include extra details that feel important but do not change the Scrum decision.

Useful facts usually answer:

• Who has the accountability?
• Which Scrum event or artifact is involved?
• What is the current goal?
• What is transparent or not transparent?
• What evidence is available?
• What decision is being requested?
• Who needs to collaborate?

Less decisive facts may include:

• Seniority of the stakeholder.
• Emotional pressure.
• A customer’s urgency without value context.
• A manager’s preferred process.
• A tool, document, or meeting name that is not part of Scrum.
• A promise made outside the Scrum Team without transparency.

Do not ignore business urgency, but do not let urgency override Scrum accountabilities.

Interpret Common Scenario Signals

“A stakeholder demands…”

This usually signals a need to listen, understand value, make trade-offs transparent, and decide through Product Backlog ordering. The Product Owner should not automatically accept or reject the demand.

Ask:

• What value does the request create?
• How does it relate to the Product Goal?
• What is the opportunity cost?
• Should the Product Backlog order change?
• Does it affect the current Sprint Goal?

“The Developers say…”

This may signal that the Product Owner needs to respect the Developers’ accountability.

Ask:

• Are the Developers discussing implementation, estimates, or Sprint Backlog management?
• Does the Product Owner need to clarify value or acceptance expectations?
• Is collaboration needed to refine or split work?

“Management wants…”

This often tests whether Scrum accountabilities remain intact under organizational pressure.

Ask:

• Is management asking for transparency, or trying to override the Product Owner or Developers?
• Can the Product Owner provide forecasts, trade-offs, and evidence?
• Is coaching needed from the Scrum Master?

“The Product Backlog is unclear…”

This points to transparency and refinement.

Ask:

• Are items ordered?
• Are near-term items clear enough?
• Are Developers involved in refinement?
• Is the Product Owner ensuring Product Backlog management is effective?

“The Increment is not Done…”

This points to the Definition of Done and transparency.

Ask:

• Is the work actually part of a usable Increment?
• Can it be released?
• Is undone work being hidden?
• What needs to be transparent before stakeholders make decisions?

Choose Between Similar Answers

PSPO I answer choices may feel close because several actions could be reasonable in real life. Choose the answer that best fits Scrum and the immediate decision.

Prefer collaboration over command

A Product Owner can make product decisions, but should not command Developers on how to do the work.

Prefer answers such as:

• Collaborate with Developers to clarify the item.
• Discuss impact on the Sprint Goal.
• Reorder the Product Backlog based on value.
• Use stakeholder feedback to adapt the Product Backlog.

Be cautious with answers that say:

• Tell Developers exactly how to implement.
• Assign tasks to individual Developers.
• Force the team to accept extra work.
• Bypass Scrum events or accountabilities.

Prefer transparency over hidden compromise

If the scenario involves uncertainty, the best answer often makes the situation visible.

Examples:

• Make progress transparent to stakeholders.
• Clarify what is and is not Done.
• Update the Product Backlog to reflect new learning.
• Communicate trade-offs rather than promising everything.

Prefer value over volume

The Product Owner is not measured simply by how many items are delivered. The Product Owner should maximize value.

When comparing answers, ask:

• Which answer improves value?
• Which answer avoids low-value output?
• Which answer uses stakeholder feedback effectively?
• Which answer supports the Product Goal?

Prefer adaptation over rigid adherence to an outdated plan

Scrum plans are useful, but they are not meant to prevent learning.

A strong answer may involve:

• Reordering the Product Backlog.
• Revising forecasts.
• Refining future work.
• Discussing changes with stakeholders.
• Inspecting progress at Sprint Review.

Mini Scenarios and Reasoning

Scenario 1: A senior stakeholder requests urgent work during the Sprint

A senior stakeholder asks the Product Owner to add a new feature immediately. The Developers are already working toward the Sprint Goal.

Reasoning path:

• The request may be valuable, but it does not automatically enter the Sprint.
• The Product Owner should consider value and urgency.
• The Product Owner should discuss impact with Developers.
• The Sprint Goal matters.
• If the item is not appropriate for the current Sprint, the Product Owner can order it in the Product Backlog for future consideration.

Most defensible next step: collaborate with Developers to understand impact and decide how to handle the request while respecting the Sprint Goal and Scrum accountabilities.

Scenario 2: Two stakeholders disagree about what should be built next

One stakeholder wants a compliance feature. Another wants a revenue-generating feature. Both insist their item is highest priority.

Reasoning path:

• Stakeholder input is important.
• The Product Owner is accountable for Product Backlog ordering.
• The decision should be based on value, risk, urgency, and product goals.
• A stakeholder vote does not replace Product Owner accountability.

Most defensible next step: gather relevant information, make trade-offs transparent, and order the Product Backlog to maximize value.

Scenario 3: Developers say a Product Backlog item is too large for the next Sprint

The Product Owner wants the item completed soon, but Developers say it is not well understood and may be too large.

Reasoning path:

• Developers provide essential input on size and feasibility.
• The Product Owner should not force the item into the Sprint unchanged.
• Refinement can improve clarity.
• Splitting the item may preserve value while reducing uncertainty.

Most defensible next step: collaborate with Developers to refine or split the item so it is better understood and appropriately ordered.

Scenario 4: A Done Increment exists, but stakeholders want to wait for Sprint Review to approve release

The Scrum Team has a Done Increment that could be released before the Sprint Review.

Reasoning path:

• A Done Increment is potentially releasable.
• Sprint Review is not required as a release approval gate.
• The Product Owner considers whether releasing now creates value.
• Stakeholder feedback matters, but release is not dependent on a ceremonial approval step.

Most defensible next step: the Product Owner decides whether to release based on value, risk, and product strategy.

Scenario 5: A roadmap promise no longer matches market feedback

Recent customer feedback suggests that planned features may be less valuable than expected.

Reasoning path:

• Scrum supports adaptation based on evidence.
• The Product Owner should not ignore new learning to protect an old plan.
• Stakeholders need transparency about changed assumptions.
• Product Backlog order may need to change.

Most defensible next step: inspect the feedback, discuss implications with stakeholders and the Scrum Team, and adapt the Product Backlog to maximize value.

Build an Answer Filter for PSPO I

Before selecting an answer, run it through this filter:

• Accountability: Is the right Scrum role doing the right thing?
• Value: Does the answer help maximize product value?
• Transparency: Does it make important information visible?
• Empiricism: Does it support inspection and adaptation?
• Product Backlog: Does it preserve Product Owner accountability for ordering and clarity?
• Sprint Goal: Does it respect the current Sprint Goal?
• Developers: Does it respect Developers’ accountability for the Sprint Backlog and Increment?
• Stakeholders: Does it use stakeholder input without letting stakeholders directly control the Scrum Team?
• Next step: Is it the most appropriate immediate action?

If an answer fails several of these checks, it is unlikely to be the best choice.

How to Practice Scenario Questions Efficiently

Use scenario practice as a reasoning exercise, not just a scoring exercise.

For each missed or uncertain question, write one sentence for each of the following:

• What role was being tested?
• What was the real decision point?
• Which Scrum accountability controlled the decision?
• What fact mattered most?
• What fact distracted me?
• Why was the correct answer more defensible than my choice?

Over time, your goal is to recognize decision patterns quickly:

• Product Backlog ordering belongs to the Product Owner.
• Sprint Backlog management belongs to the Developers.
• Scrum coaching and effectiveness support often involve the Scrum Master.
• Stakeholder pressure should be converted into transparent value trade-offs.
• New learning should lead to inspection and adaptation.
• Product value is more important than simply maximizing output.

Final Review Checklist

Before your final PSPO I review session, make sure you can answer these questions confidently:

• What is the Product Owner accountable for?
• What can the Product Owner delegate, and what remains accountable to the Product Owner?
• Who orders the Product Backlog?
• How does refinement support Product Backlog transparency?
• How should the Product Owner use stakeholder feedback?
• What is the relationship between Product Goal, Product Backlog, Sprint Goal, and Increment?
• What should happen when new information appears during a Sprint?
• When is Sprint cancellation possible?
• Who decides how work is performed during the Sprint?
• What does “Done” imply about release potential?
• How does empiricism guide product decisions?

Practical Next Step

For your next practice session, take a set of PSPO I scenario questions and pause before looking at the answers. Label the role, Scrum context, actual problem, and best next step. Then choose the answer that best supports Product Owner accountability, transparency, empiricism, and value. Use topic drills for weak areas, then confirm your timing and consistency with a full mock exam.