Try 80 free PSPO I questions across the exam domains, with answers and explanations, then continue in PM Mastery.
This free full-length PSPO I practice exam includes 80 original PM Mastery questions across the exam domains.
The questions are original PM Mastery practice questions aligned to the exam outline. They are not official exam questions and are not copied from any exam sponsor.
Official-count note: Scrum.org currently lists PSPO I as 80 questions in 60 minutes with an 85% passing score. Use Scrum.org for final exam-day rules; use this page as an original full-length PM Mastery diagnostic.
Set a 60-minute timer and answer all 80 questions in one sitting. Track each miss by the product decision you misread: Product Owner accountability, Product Backlog ordering, value evidence, stakeholder input, events, artifacts, or Scrum fundamentals.
Suggested timing checkpoints:
| Question range | Target elapsed time |
|---|---|
| 1-25 | 19 minutes |
| 26-55 | 41 minutes |
| 56-80 | 60 minutes |
| Item | Detail |
|---|---|
| Issuer | Scrum.org |
| Exam route | PSPO I |
| Official exam name | Scrum.org Professional Scrum Product Owner I (PSPO I) |
| Full-length set on this page | 80 questions |
| Exam time | 60 minutes |
| Topic areas represented | 5 |
| Topic | Approximate official weight | Questions used |
|---|---|---|
| Understanding and Applying the Scrum Framework | 22% | 18 |
| Product Owner and Backlog Management | 22% | 18 |
| Managing Products with Agility | 25% | 20 |
| Events, Artifacts, and Done for Product Ownership | 17% | 13 |
| Developing People and Teams: Self-Managing Teams | 14% | 11 |
Topic: Product Owner and Backlog Management
At a Sprint Review, three stakeholders each insist that their requested feature should be first in the Product Backlog. The Product Goal is to shorten customer onboarding, but evidence about the requests is incomplete. Which response best reflects effective Product Backlog management by the Product Owner?
Best answer: A
What this tests: Product Owner and Backlog Management
Explanation: Effective Product Backlog management stays with the Product Owner even when stakeholders provide strong input. The best response makes the Product Goal clear, uses evidence to order the Product Backlog, and preserves transparency instead of delegating or overcommitting.
The responsibility being tested is the Product Owner’s accountability for effective Product Backlog management. In this scenario, the key signals are competing stakeholder demands, incomplete evidence, and the need to connect decisions back to the Product Goal. A strong Product Owner response does three things at once: explains how requests relate to the Product Goal, uses available evidence rather than pressure to guide ordering, and keeps the Product Backlog transparent.
The Product Owner may collaborate with stakeholders and Developers, including refinement of the highest-ordered items, but accountability for ordering does not move to stakeholders or managers. Promising all requests for the next Sprint would hide uncertainty and confuse a forecast with a commitment. Waiting for complete detail before ordering also misunderstands Product Backlog refinement as an ongoing activity.
The best response shows ordering, communication, refinement, and Product Goal clarity working together.
This keeps ordering and Product Goal communication with the Product Owner while using evidence and refinement to maximize value.
Topic: Product Owner and Backlog Management
A major customer asks for an audit-export capability and sends the Product Owner a preferred technical design. Sprint Planning is tomorrow. The Developers say they need the customer need and constraints to be clear, but they want to choose the implementation themselves so they can create a Done Increment. What is the best Product Owner response?
Best answer: C
What this tests: Product Owner and Backlog Management
Explanation: The Product Owner should make the customer need transparent and ordered while leaving implementation decisions to the Developers. That supports creation of a Done Increment without taking over how the work is done.
In Scrum, the Product Owner is accountable for maximizing value and for effective Product Backlog management, including clarifying what is needed and ordering work. The Developers are accountable for deciding how to turn selected Product Backlog items into a Done Increment and for creating the Sprint plan.
Here, the best response is to clarify the customer outcome and constraints so the work is understandable and valuable, then let the Developers choose the technical approach. A customer’s preferred design can be useful input, but it should not become a task assignment from the Product Owner. The key is to give enough transparency for planning and delivery without removing Developers’ accountability for how the work is done.
A common near-miss is treating technical direction as the Product Owner’s job instead of enabling informed self-management.
This keeps Product Backlog management with the Product Owner while preserving Developers’ accountability for how selected work becomes a Done Increment.
Topic: Developing People and Teams: Self-Managing Teams
After a Sprint Review, the Scrum Team sees that a recently released onboarding change improved trial-to-paid conversion, while a heavily requested reporting feature shows very low usage. Several stakeholders now want faster priority decisions because a release forecast has slipped by two Sprints. Which response is most attractive on the surface but violates Scrum?
Best answer: D
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The tempting mistake is to centralize decisions in the name of speed. In Scrum, the Product Owner remains accountable for Product Backlog management, and Developers remain self-managing about how to do the work. New evidence should inform decisions, not justify bypassing those accountabilities.
This scenario includes real empirical signals: conversion improved, another feature has low usage, and the forecast changed. Scrum expects the Scrum Team to inspect those results and adapt. The Product Owner should collaborate with stakeholders and use the evidence to order the Product Backlog, but accountability for effective Product Backlog management stays with one Product Owner. Developers, in turn, decide how to turn selected work into a Done Increment.
A stakeholder committee reordering the Product Backlog and assigning work may sound faster because it concentrates authority, but it replaces empiricism with command-and-control and weakens self-management. A slipping forecast should increase transparency and adaptation, not shift Product Owner decisions to a committee or turn Developers into assigned resources.
The key takeaway is that efficiency-sounding shortcuts are wrong when they break Scrum accountabilities.
It may sound efficient, but it breaks Product Owner accountability for Product Backlog management and undermines Developers’ self-management.
Topic: Developing People and Teams: Self-Managing Teams
A Product Owner is preparing for a high-visibility market event on June 30. A senior leader insists that all requested features must be delivered by that date and that a lead Developer should assign tasks daily to keep everyone on track. What is the best Product Owner response?
Best answer: B
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The Product Owner should respond with transparency, not false certainty or refusal. In Scrum, leaders may express constraints such as a target date, but the Product Owner remains accountable for value and the Developers remain self-managing about how work is done.
This situation tests two Scrum boundaries at once: empirical forecasting and self-managing Developers. The Product Owner is accountable for maximizing product value and for effective Product Backlog management, so the best response is to order work by value and communicate what is most likely by June 30 based on current evidence. A fixed date can be discussed transparently, but promising fixed scope despite uncertainty is not empirical Scrum.
At the same time, assigning daily tasks through a lead Developer creates hierarchy inside the Scrum Team and interferes with Developers’ self-management. Leaders and stakeholders can provide goals, constraints, and feedback, but they should not control how Developers perform Sprint work.
The key is to make uncertainty visible while preserving Scrum Team accountabilities.
This keeps value decisions with the Product Owner, treats the date as a forecast under uncertainty, and preserves Developers’ self-management.
Topic: Events, Artifacts, and Done for Product Ownership
A Scrum Team completed a Done Increment at the end of the Sprint. It meets the Definition of Done and was shown at the Sprint Review, where stakeholders said releasing it now would help retain several at-risk customers, although more features are still expected later. What is the best interpretation for the Product Owner?
Best answer: B
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: In Scrum, a Done Increment is usable and makes quality transparent through the Definition of Done. Whether to release it is still a product-value decision, informed by stakeholder feedback, market timing, and the Product Owner’s accountability for maximizing value.
The key distinction is between product value and product quality transparency. The Definition of Done tells everyone that the Increment meets the agreed quality standard and is usable. That creates transparency and enables release, but it does not require release.
Here, the Sprint Review produced a value signal: releasing now may help retain at-risk customers. Interpreting that evidence and deciding whether to release is part of maximizing product value, which is the Product Owner’s accountability. A release can happen before the full Product Goal is achieved, as long as there is a Done Increment worth releasing.
The closest mistake is treating “Done” as either an automatic release trigger or as proof that release must wait for all planned features.
A Done Increment is usable and transparent in quality, while the release decision remains a value decision for the Product Owner.
Topic: Product Owner and Backlog Management
A senior sales stakeholder messages the Product Owner during a Sprint: “A customer wants CSV export. Put it at the top immediately, update the project schedule, assign the team’s remaining work, and send me the feature for approval before release.” Which response is best?
Best answer: A
What this tests: Product Owner and Backlog Management
Explanation: The best response preserves Scrum accountabilities while still meeting the stakeholder’s need for transparency. The Product Owner manages Product Backlog ordering, the Developers manage the Sprint Backlog and how work is done, and stakeholder feedback does not create a required approval workflow.
This scenario mixes several different responsibilities. The Product Owner is accountable for effective Product Backlog management, so the stakeholder request should be considered in Product Backlog ordering based on value, Product Goal alignment, and evidence. The Developers, not the Product Owner or stakeholder, manage the Sprint Backlog and decide how to do the work during the Sprint. Scrum also does not require stakeholder approval for a usable Increment; transparency comes from inspecting a Done Increment, not from adding a sign-off gate.
A good response should do three things:
The closest distractors either delegate Product Backlog decisions, turn the Product Owner into a task assigner, or hide uncertainty instead of communicating it transparently.
This keeps Product Backlog management with the Product Owner, Sprint Backlog management with the Developers, and avoids turning release decisions into a stakeholder sign-off gate.
Topic: Understanding and Applying the Scrum Framework
At the end of a Sprint, the Developers produce an Increment that meets the Scrum Team’s Definition of Done and is usable. During the Sprint Review, stakeholders are satisfied, but the PMO says nothing may be released until a monthly release board approves it and every Product Backlog item has a story-point estimate recorded in the tool. What is the best interpretation?
Best answer: D
What this tests: Understanding and Applying the Scrum Framework
Explanation: Scrum requires a usable Increment that meets the Definition of Done by the end of each Sprint. A release board, formal approval gate, and mandatory story-point entry may exist in an organization, but they are not Scrum requirements.
The key distinction is between Scrum rules and organization-specific additions. In Scrum, an Increment is considered Done when it meets the Definition of Done and is usable. Scrum does not require a monthly release board, stakeholder sign-off, or story-point estimates in a tool. Those may be local governance practices or optional techniques, but they are not part of the Scrum framework itself.
The Sprint Review is used to inspect the outcome of the Sprint and adapt what to do next, not to serve as a formal acceptance gate. Likewise, estimation approaches such as story points can be helpful, but Scrum does not mandate them. The important takeaway is to avoid confusing external controls and optional practices with Scrum’s actual rules.
Scrum requires a usable Increment that meets the Definition of Done each Sprint; release boards and mandatory story points are outside the framework.
Topic: Managing Products with Agility
A Product Owner highlights success by counting how many features are released each Sprint. The count keeps rising, but stakeholders still cannot tell whether customer behavior improved, and Developers start splitting work into smaller items to raise the number. Which study term best matches this kind of metric?
Best answer: C
What this tests: Managing Products with Agility
Explanation: This is a vanity metric because it rewards visible output without showing whether customers or the business are actually better off. It also creates misleading incentives by encouraging count optimization instead of empirical learning and progress toward the Product Goal.
A vanity metric is a measure that looks impressive but does not help the Product Owner or stakeholders understand whether the product is delivering meaningful outcomes. In this case, counting released features can rise even when customer behavior, adoption, satisfaction, or business results do not improve. That makes the metric easy to game and weak for evidence-based adaptation.
In Scrum, useful measures should increase transparency and support inspection and adaptation toward the Product Goal. A metric that pushes Developers to maximize item counts can distort behavior, reduce learning, and conflict with self-management by rewarding output over value. The closer idea is an outcome metric, but that would measure the effect of the work, not just the amount shipped.
It looks positive on the surface but can be gamed and does not provide reliable evidence of value, learning, or Product Goal progress.
Topic: Understanding and Applying the Scrum Framework
A Product Owner says, “We may reorder or rewrite items as we learn, but this long-term objective keeps the Scrum Team aligned on why the product is being improved.” Which Scrum concept is being described?
Best answer: A
What this tests: Understanding and Applying the Scrum Framework
Explanation: The description matches the Product Goal because it is the long-term objective that gives direction to the evolving Product Backlog. The Product Backlog may change as the Scrum Team learns, but the Product Goal provides enduring focus.
In Scrum, each artifact has a related commitment that improves transparency. The Product Backlog is the ordered list of what might improve the product, while the Product Goal is its commitment: the long-term objective the Scrum Team works toward. That is why the statement contrasts changing backlog items with a stable direction.
The nearby distinctions are important:
So when the description emphasizes a long-term objective that guides changing backlog items, it refers to the Product Goal, not the backlog itself or a Sprint-level commitment.
The Product Goal is the long-term objective for the Scrum Team and the commitment for the Product Backlog.
Topic: Product Owner and Backlog Management
A Product Owner is considering moving a new “CSV export for managers” item above several onboarding improvements.
Evidence so far
Product Goal: Reduce customer support contacts by making account setup self-service.
Recent Sprint Review:
- Done Increment: simplified setup flow
- Result: setup completion rose from 62% to 74%
- Stakeholder input: Sales says CSV export may help close one pending deal
Release expectation:
- Current forecast assumes the next 3 top items continue improving onboarding
Before reordering items that could change Product Goal progress and the release expectation, what evidence is most needed?
Best answer: B
What this tests: Product Owner and Backlog Management
Explanation: The Product Owner should seek evidence that the new item improves value enough to justify changing Product Goal progress and release expectations. In Scrum, ordering is based on value, risk, learning, and contribution to the Product Goal, while release expectations remain forecasts informed by empirical progress.
The key concept is empirical Product Backlog ordering. The current evidence shows onboarding changes are already improving a result tied directly to the Product Goal, while the new export request is supported only by one stakeholder opinion. Before changing the order, the Product Owner needs better evidence that the new item creates more value than the current work and to understand how that change affects the release forecast.
Useful evidence would include:
Detailed estimates, executive approval, or scope guarantees do not replace evidence-based ordering. The closest distractor is the estimate option, but effort data alone does not show value or Product Goal impact.
Reordering should be guided by evidence of greater value and Product Goal contribution, then reflected in an empirical release forecast.
Topic: Understanding and Applying the Scrum Framework
A Product Owner sees that Sprint Reviews rarely lead to meaningful adaptation. In the last two Sprints, no Increment met the Definition of Done, most attendees were managers rather than users or customer representatives, and the Product Backlog shown at the review did not clearly indicate order or progress toward the Product Goal. What is the best action?
Best answer: A
What this tests: Understanding and Applying the Scrum Framework
Explanation: Scrum relies on transparency for inspection and adaptation. Without a Done Increment, useful stakeholder feedback, and visible Product Backlog information, the Sprint Review cannot effectively inform product decisions.
The core issue is ineffective inspection caused by missing transparency. A Sprint Review is meant to inspect the outcome of the Sprint and adapt the Product Backlog based on what was learned. If nothing is Done, the Scrum Team lacks a usable Increment to inspect. If the wrong stakeholders attend, feedback is unlikely to help maximize product value. If Product Backlog order and Product Goal progress are unclear, adaptation decisions are weak or speculative.
The best response is to restore the conditions for empiricism:
Approving unfinished work or replacing inspection with more output reduces transparency instead of improving it.
Inspection is effective only when there is a usable Done Increment, relevant feedback, and transparent Product Backlog information to support adaptation.
Topic: Events, Artifacts, and Done for Product Ownership
During a Sprint, the Scrum Team is working toward this Sprint Goal: “Reduce trial-user drop-off during account setup.” Mid-Sprint, feedback from a newly released Increment shows users are mainly abandoning setup at identity verification, not at profile customization. The Product Owner explains that improving verification flow would better support the Sprint Goal than finishing the remaining customization tasks. What is the best interpretation of this situation?
Best answer: C
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: This is primarily a collaboration boundary question. The Product Owner provides product-value clarification based on new evidence, and the Developers decide how to adapt the Sprint Backlog while still pursuing the Sprint Goal.
In Scrum, the Sprint Backlog belongs to the Developers, and they adapt it as needed during the Sprint. The Product Owner is accountable for maximizing product value and can clarify what now appears most valuable based on feedback or evidence. In this case, the new feedback changes the understanding of where value is created, so the Product Owner should clarify that impact. Then the Developers decide how to change their plan and selected work to best achieve the Sprint Goal.
The key distinction is:
The closest misconception is treating Sprint Planning as a fixed scope contract; Scrum expects adaptation when new learning emerges.
The Product Owner clarifies value and Sprint Goal implications, while the Developers self-manage changes to the Sprint Backlog plan.
Topic: Managing Products with Agility
A Scrum Team’s Product Goal is to increase self-service customer renewals. At the Sprint Review, a Done Increment for a new partner portal shows almost no usage and no effect on renewals. A senior executive says the Product Owner should keep portal enhancements at the top of the Product Backlog because “we already spent six Sprints on it,” while a sales director wants more portal work to help her department hit an internal target. What is the most appropriate next step for the Product Owner?
Best answer: A
What this tests: Managing Products with Agility
Explanation: Past investment and departmental targets are not evidence of product value. The Product Owner should inspect the Sprint Review evidence with stakeholders and adapt Product Backlog ordering toward work most likely to advance the Product Goal.
In Scrum, the Product Owner is accountable for maximizing product value and for effective Product Backlog management. Here, the latest evidence shows the portal is not contributing to the Product Goal of increasing renewals, so the next step is to inspect that evidence with stakeholders, learn from it, and reorder the Product Backlog toward higher-value options. The six Sprints already spent are a sunk cost, and a department’s internal target is a local optimization; neither justifies continued investment by itself. Stakeholder input matters, but stakeholders do not take over Product Backlog ordering. The key response is evidence-based adaptation tied to strategic value, not political pressure or attempts to justify past spending.
The Product Owner should adapt Product Backlog ordering based on evidence and the Product Goal, not sunk cost or departmental targets.
Topic: Understanding and Applying the Scrum Framework
A department head tells a Scrum Team, “Starting next Sprint, split into a business sub-team and an engineering sub-team. A tech lead should approve Developers’ work, and sales and support can jointly act as Product Owner so customer requests move faster.” Which response best reflects Scrum?
Best answer: D
What this tests: Understanding and Applying the Scrum Framework
Explanation: Scrum defines the Scrum Team as one Product Owner, one Scrum Master, and Developers working as a single unit. Stakeholders can provide input, but they do not replace the Product Owner, and internal sub-teams or approval hierarchies are not part of Scrum.
The core concept is that a Scrum Team is one cohesive, self-managing team composed of exactly one Product Owner, one Scrum Master, and Developers. In this scenario, splitting the team into business and engineering sub-teams and adding a tech-lead approval layer would introduce internal hierarchy, which conflicts with Scrum. Making sales and support jointly act as Product Owner would also break the rule that the Product Owner is one person, even when many stakeholders contribute input.
Specialized skills may exist, but the Scrum Team still remains one team. Stakeholders such as sales and support collaborate with the Product Owner by sharing customer insights, constraints, and feedback. The Product Owner remains accountable for Product Backlog decisions, while Developers remain accountable for how they turn selected work into a Done Increment.
The key takeaway is to preserve one team and clear accountabilities rather than adding committees or internal chains of command.
Scrum defines one Scrum Team with no sub-teams or hierarchies, and the Product Owner accountability belongs to one person.
Topic: Product Owner and Backlog Management
The Product Goal is to improve first-month retention for a SaaS product. At the Sprint Review, pilot data showed most customers abandon the product during setup, while only 3% used the previously requested reporting export. The Product Backlog still has one large, highly ordered item: “Advanced export dashboard and custom report pack.” Sales asks to keep it at the top for an upcoming conference. What is the best Product Owner response before the next Sprint Planning?
Best answer: D
What this tests: Product Owner and Backlog Management
Explanation: The best response is to adapt the Product Backlog based on what was learned. The new evidence shows setup problems matter more to the Product Goal than the large export item, so the Product Owner should refine the item, increase transparency, and reorder accordingly.
Product Backlog refinement is driven by empirical product learning. Here, the Product Goal is retention, and the new evidence shows setup friction is a larger value opportunity than the previously requested export capability. The Product Owner is accountable for effective Product Backlog management, so the right response is to make the backlog more transparent and better ordered by splitting a large assumption-heavy item, clarifying any smaller evidence-backed part, and deferring or removing the rest if it no longer supports the Product Goal.
That approach does three useful things:
The closest distractors either hand off Product Owner accountability, accept stakeholder pressure without evidence, or delay adaptation despite already having enough learning to refine now.
This uses empirical learning to refine the item and reorder the Product Backlog toward the Product Goal instead of preserving an assumption-based item unchanged.
Topic: Product Owner and Backlog Management
A Product Owner is often unavailable because of customer and sales meetings. During the last two Sprints, Developers waited several days for answers about user needs and business rules. To avoid blocking work, they made their own product assumptions, and Sprint Review feedback showed the Increment did not meet an important customer need.
What is the best action?
Best answer: D
What this tests: Product Owner and Backlog Management
Explanation: Poor Product Owner availability creates delays, weakens transparency, and encourages Developers to fill gaps with unsupported assumptions. The best response is to restore timely Product Owner collaboration so product decisions and Product Backlog management remain visible and accountable.
The core issue is not developer capability; it is missing product transparency caused by limited Product Owner availability. When Developers cannot get timely answers about user needs or business rules, they may guess, which increases the risk of building the wrong thing and slows feedback. The Product Owner is accountable for maximizing value and for effective Product Backlog management, so the best action is to be available often enough to clarify questions, make product decisions transparent, and adapt the Product Backlog as new information emerges.
A practical response is to:
Using a proxy or relying on guesses may keep work moving temporarily, but it weakens accountability and value-focused decision-making.
Timely Product Owner collaboration improves transparency, reduces unsupported assumptions, and keeps product decisions with the accountable person.
Topic: Developing People and Teams: Self-Managing Teams
A Scrum Team can complete coding for new checkout features each Sprint, but every Sprint the work waits for a separate testing department and a separate UX group before it can be used. Stakeholders are frustrated that value reaches customers only every few Sprints.
Which response is best?
Best answer: B
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: Cross-functionality enables the Scrum Team to create value each Sprint by having the essential capabilities needed to produce a usable Done Increment. When testing and UX depend on outside handoffs for core work, value is delayed and transparency is reduced.
In Scrum, cross-functionality means the Scrum Team collectively has the skills needed to create value each Sprint. In this scenario, coding is not enough because testing and UX work are essential to making the Increment usable. If those activities depend on outside departments, the team cannot reliably deliver a Done Increment each Sprint and stakeholders receive value later than expected.
The strongest response is to reduce those essential handoffs by building or securing the needed capabilities within the Scrum Team. External specialists can still collaborate or advise, but the team should not rely on outside groups to complete core work required for Done. Tightening coordination or asking stakeholders for patience does not solve the underlying dependency.
The key takeaway is that cross-functionality supports end-to-end value delivery, not just faster completion of one type of work.
Cross-functionality means the Scrum Team has the essential skills to deliver a usable Done Increment without relying on external handoffs for core work.
Topic: Developing People and Teams: Self-Managing Teams
Several line managers say the Developers are “too autonomous” and ask the Product Owner to assign daily work, approve technical approaches, and track individual output to improve predictability. The Product Owner wants a correction that supports delivery without weakening Scrum. Which response is best?
Best answer: D
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The best correction keeps accountabilities where Scrum places them. The Product Owner should maximize value and manage the Product Backlog, while Developers self-manage how to create a Done Increment, and the Scrum Master helps managers understand those boundaries.
In Scrum, the Product Owner is accountable for maximizing value and for effective Product Backlog management, not for directing Developers’ day-to-day work. Developers are self-managing and decide how to turn selected Product Backlog items into a Done Increment during the Sprint. When managers want more control for predictability, the correction is not to add task assignment or hierarchy inside the Scrum Team. Instead, preserve accountability: the Product Owner clarifies value, goals, and ordering; Developers manage the Sprint work; and the Scrum Master helps the managers understand Scrum and remove organizational misunderstandings. That approach supports transparency and delivery without undermining self-management. Detailed daily direction may look efficient in the short term, but it weakens the Developers’ accountability and misuses the Product Owner role.
This preserves Product Owner accountability for value, Developers’ self-management for doing the work, and the Scrum Master’s accountability to help the organization understand Scrum.
Topic: Product Owner and Backlog Management
A Product Owner has ordered a Product Backlog item for a new refund flow at the top of the Product Backlog. During Sprint Planning, Developers say the item’s business rules are still unclear because Sales and Compliance gave conflicting input, and they are unsure they can create a Done Increment from it this Sprint. Stakeholders still want fast progress. What is the best action for the Product Owner?
Best answer: C
What this tests: Product Owner and Backlog Management
Explanation: The Product Owner should increase clarity around value and business rules so Developers have enough understanding to select work that can become Done. That supports effective Product Backlog management without taking over the Developers’ accountability for how the work is performed.
The core concept is the boundary between Product Owner accountability and Developers accountability. The Product Owner is accountable for effective Product Backlog management, including making Product Backlog items transparent enough for useful inspection, selection, and refinement. In this case, conflicting stakeholder input makes the item too unclear for confident Sprint Planning.
The best response is to collaborate with stakeholders and Developers to clarify the outcome, resolve or expose the business-rule conflict, and refine or split the item if needed. That enables Developers to make a realistic forecast and create a Done Increment. The Product Owner supports value and clarity, but Developers still decide how the selected work will be done.
The key takeaway is: clarify the what and why, not direct the how.
This improves Product Backlog transparency so Developers can forecast useful work while preserving their accountability for how the Increment is created.
Topic: Understanding and Applying the Scrum Framework
After a Sprint Review, usage data for a new onboarding feature is inconclusive. Sales wants more customization next, while Support wants a simpler setup. The Product Owner tells stakeholders the release forecast will stay unchanged and asks the Scrum Team not to raise the disagreement until “the data is clearer.” What is the best response?
Best answer: A
What this tests: Understanding and Applying the Scrum Framework
Explanation: The Product Owner undermines openness by hiding uncertainty, stakeholder conflict, and forecast risk. A better response is to make those facts transparent and use evidence to adapt Product Backlog ordering and any release forecast.
Openness in Scrum means important product information is visible, especially when it affects value decisions. In this scenario, the Product Owner is suppressing three things that matter: inconclusive value evidence, conflicting stakeholder input, and uncertainty in the release forecast. That reduces transparency and weakens empirical decision-making.
The better response is to expose those realities and inspect them with stakeholders and the Scrum Team. The Product Owner remains accountable for Product Backlog ordering, but that ordering should reflect visible evidence, trade-offs, and uncertainty rather than a falsely stable message. A forecast is not a commitment, so hiding risk to appear confident is inconsistent with Scrum.
The key takeaway is that openness supports better value decisions; it is not optional when the evidence is unclear.
Openness requires making uncertainty, conflicting stakeholder input, and forecast risk visible so the Product Owner can inspect and adapt.
Topic: Managing Products with Agility
A Product Owner’s Product Goal is to help new merchants receive their first customer payment sooner. After releasing a simplified onboarding flow to 25% of new merchants, the Scrum Team inspects these results at the Sprint Review:
Which is the best interpretation for the Product Owner to use when adapting the Product Backlog?
Best answer: C
What this tests: Managing Products with Agility
Explanation: The best metric is the one that shows whether customer behavior changed in the direction of the Product Goal. Here, faster first payments are an outcome tied to value, while page views, completed items, and utilization do not by themselves show improved product results.
Product Owners should favor evidence that shows whether the product is producing a valuable customer or business result. In this scenario, the Product Goal is about helping merchants receive their first payment sooner, so the increase in merchants achieving that result within 7 days is the strongest signal of progress.
The other measures can still be useful operationally, but they do not directly show product value:
A good next step is to inspect whether the pilot result is meaningful and then adapt Product Backlog ordering based on that evidence, rather than on activity or output counts alone.
It measures a customer result tied directly to the Product Goal, so it is the best outcome evidence for adaptation.
Topic: Product Owner and Backlog Management
A Product Owner shows this Product Backlog note before Sprint Planning: “Top items will be ordered each week by a stakeholder committee vote. I will avoid changing their ranking so no one feels ignored.” What is the best management response?
Best answer: A
What this tests: Product Owner and Backlog Management
Explanation: This setup weakens Product Owner accountability by turning Product Backlog ordering into committee control. The Product Owner should collaborate with stakeholders, but still make and own the final ordering decisions to maximize product value.
In Scrum, the Product Owner is one person accountable for maximizing the value of the product and for effective Product Backlog management. Stakeholders should provide input, constraints, and feedback, but committee voting does not replace Product Owner decision rights. In this scenario, the issue is not lack of visibility; it is unclear accountability. A transparent voting method may surface preferences, yet the Product Owner must still weigh those preferences against the Product Goal, evidence, risk, and overall value. Developers also do not take over product priority decisions just because they understand implementation trade-offs. The key takeaway is that input can be shared, but Product Owner accountability cannot be diluted.
Stakeholders can inform priorities, but the Product Owner remains accountable for ordering the Product Backlog to maximize value.
Topic: Developing People and Teams: Self-Managing Teams
A senior manager tells a Scrum Team, “Scrum requires a separate weekly refinement meeting, every Product Backlog item must be in user story format, and nothing should enter Sprint Planning until it has an estimate.” The team asks how to respond. Which response is best?
Best answer: B
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: Scrum does not require a formal refinement event, a user story format, or estimates for every Product Backlog item. The best response corrects the misconception and still helps the audience by explaining that the Scrum Team should use whatever practices create enough understanding for planning and forecasting.
The core concept is that Scrum defines accountabilities, events, artifacts, and commitments, but it does not mandate a separate refinement event, a specific Product Backlog item format, or estimates on every item. Product Backlog refinement is ongoing work, not a required ceremony, and teams may use techniques such as user stories, roadmaps, or estimates when they are helpful.
A strong response should do two things:
Weaker responses either hand decisions to the wrong people, turn optional techniques into compliance rules, or dismiss the need to communicate how planning will still work.
It correctly separates optional practices from Scrum requirements while still supporting transparency and planning.
Topic: Understanding and Applying the Scrum Framework
A Scrum Team building a subscription product has strong UX and API specialists, but recent Sprints have suffered from handoffs between them. Before Sprint Planning, the sales director asks the Product Owner to assign a pricing-change Product Backlog item to the API specialist because “she is the only one who can do it fast.” The Developers say they can achieve a valuable Sprint Goal if they decide together how to do the work. What is the best action for the Product Owner?
Best answer: C
What this tests: Understanding and Applying the Scrum Framework
Explanation: The Product Owner should keep Product Backlog ordering and value decisions, then let the Developers decide how to turn selected work into a Done Increment. That respects self-management and avoids reinforcing specialist silos that weaken cross-functionality.
In Scrum, the Product Owner is accountable for maximizing value and for effective Product Backlog management, including ordering. The Developers are accountable for creating the plan for the Sprint and deciding how to accomplish the work. In this scenario, the Product Owner should explain the value of the pricing change, keep the item properly ordered, and let the Developers determine who works on it and how they collaborate.
This approach preserves two key boundaries:
Choosing the fastest specialist may seem efficient, but it undermines self-management and reinforces handoffs.
The Product Owner keeps accountability for value and Product Backlog ordering, while the Developers self-manage how to deliver a Done Increment.
Topic: Understanding and Applying the Scrum Framework
After each Sprint Review, a steering committee now meets privately to rank new requests before the Product Owner may reorder the Product Backlog. Over two Sprints, urgent customer feedback waited a week to appear in the backlog, Sprint Planning was postponed once, and Developers stopped discussing trade-offs with the Product Owner because “the committee decides anyway.” What is the best interpretation of this added practice?
Best answer: D
What this tests: Understanding and Applying the Scrum Framework
Explanation: This practice undermines Scrum rather than strengthening it. Stakeholder input is useful, but making a committee control Product Backlog ordering shifts Product Owner accountability and slows inspection and adaptation.
In Scrum, stakeholders can provide feedback and constraints, but the Product Owner remains accountable for effective Product Backlog management, including ordering. Here, the evidence shows the added practice is not just creating transparency; it is making a committee the real decision-maker. That weakens Product Owner accountability, reduces direct collaboration with Developers, and delays adaptation to new customer feedback.
A supporting practice would increase transparency while preserving accountabilities, for example by making feedback visible or helping the Product Owner inspect value signals faster. This committee does the opposite because it creates a gate before backlog changes can happen. The key takeaway is that added practices are only helpful when they support empiricism without taking decisions away from the Scrum accountabilities.
Product Backlog ordering remains the Product Owner’s accountability, and delaying it through committee control weakens adaptation.
Topic: Managing Products with Agility
At a Sprint Review, Sales stakeholders ask for six new dashboard features they believe will help win deals. The Product Goal is to increase conversion from trial to paid subscriptions. Data from the last two Done Increments shows dashboard usage is low, while a small onboarding change increased trial completion by 15%. What is the best response from the Product Owner?
Best answer: C
What this tests: Managing Products with Agility
Explanation: The strongest response is to use evidence and the Product Goal to guide Product Backlog ordering. Stakeholder input matters, but the Product Owner remains accountable for maximizing value and should make the rationale transparent rather than following the loudest request.
This scenario is about evidence-based value decisions. The Product Goal is increasing trial-to-paid conversion, and the available evidence shows onboarding improvements are contributing to that outcome, while dashboard usage is low. The Product Owner should therefore reorder the Product Backlog toward the work most likely to improve the desired outcome, while openly sharing the data and continuing to inspect results with stakeholders.
In Scrum, stakeholders provide input and feedback, but they do not directly control Product Backlog ordering. Developers also do not take over value prioritization from the Product Owner. Waiting for unanimous stakeholder agreement delays adaptation and weakens accountability. The best choice preserves Product Owner accountability, uses empiricism, and focuses on outcomes over feature output.
This keeps Product Backlog ordering with the Product Owner and uses evidence tied to the Product Goal to maximize value.
Topic: Events, Artifacts, and Done for Product Ownership
During Sprint Planning, the Developers say the highest-ordered Product Backlog items are too unclear: they do not understand the user value, the intended scope, or what would make the work acceptable. A senior stakeholder pressures the team to take those items anyway because of an announced target date. What is the best Product Owner action?
Best answer: D
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The Product Owner should improve Product Backlog transparency so Developers understand why the work matters and what acceptable outcomes look like before selecting items for the Sprint. Stakeholder pressure does not replace clarity, and Scrum does not require exhaustive upfront specification.
This situation is about effective Product Backlog management and Sprint Planning readiness. The Product Owner is accountable for maximizing value and for making sure the Product Backlog is transparent enough that Developers can understand the value of items, their intended scope, and what acceptable results mean in context of the Product Goal. If the highest-ordered items are too unclear, the best response is to collaborate and refine them, then reorder if needed, rather than forcing unclear work into the Sprint.
The closest distractor is taking the items anyway, but that hides uncertainty instead of using empiricism transparently.
The Product Owner is accountable for effective Product Backlog management and should create enough transparency for Developers to make a sound Sprint selection.
Topic: Understanding and Applying the Scrum Framework
At the end of a Sprint, a Product Owner reviews the Developers’ status against the current Definition of Done:
Definition of Done:
- integrated
- security tested
- user documentation updated
PBI status:
- New search filter: integrated, documentation updated, not security tested
- CSV export: integrated, security tested, documentation updated
- Audit trail: security tested only
Which interpretation is most consistent with Scrum?
Best answer: B
What this tests: Understanding and Applying the Scrum Framework
Explanation: The Definition of Done makes quality expectations explicit for everyone. In this scenario, only the CSV export satisfies every required quality measure, so only that work is part of the Increment and transparent as done.
In Scrum, the Definition of Done is the commitment for the Increment and creates transparency about the quality measures required before work can be considered part of that Increment. The key implication in this scenario is not how close each item is, but whether each one fully meets the stated quality bar.
Because the search filter is missing security testing and the audit trail is missing integration and documentation updates, neither meets the Definition of Done. Only the CSV export does. This prevents partially completed work from being mistaken for usable product progress and gives the Product Owner and stakeholders a clear, shared basis for inspection. Close-to-done work may still have value later, but it is not yet part of the Increment.
An Increment includes only work that meets the Definition of Done, which makes the required quality measures transparent.
Topic: Managing Products with Agility
A Product Owner is inspecting recent product evidence.
Exhibit:
What is the best next action?
Best answer: B
What this tests: Managing Products with Agility
Explanation: The evidence shows more people are signing up, but fewer are becoming active users and conversions are not improving. The Product Owner should respond to that outcome signal by reordering the Product Backlog toward activation, inspecting whether the current Product Goal still best reflects value, and communicating an updated forecast transparently.
Metric evidence should guide empirical adaptation, not just confirm output. Here, acquisition improved, but the value signal that matters for the Product Goal and business outcome is weak: activation dropped, conversions stayed flat, and Sprint Review feedback identifies setup friction. That means the Product Owner should order the Product Backlog toward the biggest constraint to value, which is activation rather than more landing pages.
The Product Owner should also inspect whether the current Product Goal still represents the most valuable longer-term objective. If activation is now the real bottleneck to active usage, the goal may need to be adapted. Stakeholder communication should be transparent and evidence-based, focusing on what was learned and how forecasts change under that learning.
Waiting for more output or handing ordering to others reduces empiricism and weakens Product Owner accountability.
The evidence shows acquisition is improving but value realization is blocked in activation, so backlog ordering, Product Goal inspection, and stakeholder communication should all reflect that learning.
Topic: Managing Products with Agility
A product’s vision is to help independent retailers launch online stores in one day. The current Product Goal is to expand advanced campaign automation, and the top Product Backlog items continue that work. After three Sprints, telemetry shows automation features are rarely used, while most new retailers abandon setup before publishing their first store. One sales stakeholder still wants more automation for a large prospect. What should the Product Owner do next?
Best answer: C
What this tests: Managing Products with Agility
Explanation: The Product Owner should inspect the new evidence and adapt when the current Product Goal no longer supports the product vision. That may mean abandoning an obsolete Product Goal and reordering the Product Backlog transparently to maximize value.
The key concept is strategic alignment through empiricism. The product vision describes the broader direction, while the Product Goal is the current long-term objective for the Product Backlog. Here, evidence from Done Increments shows the team is improving an area with low usage while customers struggle with the core outcome the vision promises.
The Product Owner is accountable for maximizing value and for effective Product Backlog management, so the response is to use the evidence, make the situation transparent, and adapt. If the current Product Goal is no longer the best path toward the vision, it can be abandoned as obsolete and replaced with a better one, with the Product Backlog reordered accordingly.
Preserving the plan, serving one loud stakeholder, or shifting value decisions to Developers each ignores that accountability.
This uses evidence to realign the Product Goal and Product Backlog with the product vision while keeping Product Owner accountability for value.
Topic: Understanding and Applying the Scrum Framework
A key customer tells the Product Owner, “Move this integration to the top of the Product Backlog and tell the Developers to use vendor X so we can announce it next month.” The Developers reply that they need clearer value, constraints, and Product Goal relevance before Sprint Planning. What is the best Product Owner response?
Best answer: D
What this tests: Understanding and Applying the Scrum Framework
Explanation: The Product Owner should collaborate to make value, stakeholder needs, and Product Goal relevance transparent, while leaving implementation decisions to Developers. That keeps Product Backlog management effective without crossing into controlling how the work is done.
The core concept is Product Owner accountability with healthy collaboration boundaries. The Product Owner is accountable for maximizing value and for effective Product Backlog management, so they should clarify why the integration matters, what constraints exist, and how it supports the Product Goal. Developers then use that transparency to determine how to turn the selected work into a Done Increment.
In this scenario, the best response does two things at once: it improves Product Backlog understanding for Sprint Planning, and it avoids directing the technical solution. Customer input is important, but it does not transfer Product Backlog ordering accountability to Developers or let stakeholders dictate implementation. A public date promise without evidence would also confuse forecast with certainty.
The key takeaway is: clarify value and needs collaboratively, but leave implementation choices to Developers.
This preserves the Product Owner’s accountability for value and Product Backlog clarity without directing how Developers do the work.
Topic: Product Owner and Backlog Management
A Product Owner shares this Sprint Review summary for a subscription product:
Product Goal: Increase trial-to-paid conversion for small businesses.
Evidence from the latest Increment:
- 68% of trial users used the new dashboard.
- The largest drop-off is still at payment setup.
- Three enterprise prospects asked for SSO during sales calls.
- The COO wants "AI summary export" shown at next month's board meeting.
Which Product Backlog ordering decision best indicates the Product Owner is using politics or deadline pressure instead of product value and evidence?
Best answer: A
What this tests: Product Owner and Backlog Management
Explanation: The weak signal is ordering work mainly to satisfy executive visibility at a fixed date. In Scrum, Product Backlog ordering should be driven by value, risk, learning, and progress toward the Product Goal, not by politics or display needs.
The core concept is that the Product Owner orders the Product Backlog to maximize value, using evidence and Product Goal alignment. Here, the strongest evidence points to payment setup as the conversion problem, and customer input about SSO could justify learning or value discovery. By contrast, moving AI summary export to the top only because leaders want to see it at a board meeting is a political and deadline-driven choice.
Good ordering signals in this scenario include:
Stakeholder requests matter, but they are input, not automatic priority. Ordering by visibility, arrival order, feature count, or utilization weakens empiricism and can reduce product value.
This ordering is driven by stakeholder visibility and timing pressure, not by evidence, learning, risk reduction, or Product Goal contribution.
Topic: Product Owner and Backlog Management
During a Sprint Review, three stakeholders each insist their request must be placed at the top of the Product Backlog for the next Sprint. One executive sends the Developers a ranked list and asks them to start preparing the work. The Product Goal remains unchanged, and recent customer feedback is available. What is the next most appropriate step for the Product Owner?
Best answer: A
What this tests: Product Owner and Backlog Management
Explanation: Stakeholders can provide important input, but they should not control Product Backlog ordering. The Product Owner should inspect the requests using the Product Goal and available evidence, then adapt the backlog and communicate the rationale clearly.
This situation shows a Product Owner accountability risk: stakeholders are trying to directly control Product Backlog ordering. In Scrum, the Product Owner is accountable for maximizing value and for effective Product Backlog management, including ordering. The right next step is to inspect the new requests against the Product Goal, current customer feedback, and other value considerations, then adapt the Product Backlog accordingly.
Stakeholders should influence decisions with input and evidence, not by issuing priority commands to Developers. Developers may help clarify and refine items, but they do not decide product value priorities. The Scrum Master can coach Scrum accountability boundaries, but does not take over ordering decisions. The key takeaway is to restore transparency and Product Owner accountability rather than letting stakeholder pressure become backlog control.
The Product Owner restores accountability by using evidence and Product Goal alignment to order the Product Backlog and making that rationale transparent.
Topic: Events, Artifacts, and Done for Product Ownership
At a Sprint Review, the Scrum Team demonstrates a Done Increment for a subscription product. The Product Goal is to reduce trial-user drop-off. Stakeholders like the new onboarding flow, customer support reports confusion during account setup, and sales asks for a firm launch date. Which Product Owner response is best?
Best answer: A
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The Sprint Review is for inspecting the Done Increment, discussing progress toward the Product Goal, gathering stakeholder feedback, and considering Product Backlog adaptations. The best response is transparent about the current forecast and uses the feedback to inform ordering decisions without handing that accountability to stakeholders.
A Sprint Review is not just a demo and not a commitment meeting. Its purpose is to inspect the outcome of the Sprint with stakeholders, consider progress toward the Product Goal, and determine what adaptations are most valuable next. In this scenario, the Product Owner should make the Done Increment visible, discuss what the new feedback means for customer value, and update the Product Backlog as needed.
That also means being transparent about uncertainty. A forecast can be discussed, but a firm date should not be promised without evidence. Stakeholders contribute important input, but they do not take over Product Backlog ordering. The strongest response combines inspection, feedback, transparency, and adaptation in one conversation.
This uses the Sprint Review for inspection and adaptation while keeping Product Backlog ordering accountable to the Product Owner.
Topic: Events, Artifacts, and Done for Product Ownership
Midway through a Sprint, the Developers use the Daily Scrum to inspect progress and realize the main Product Backlog item selected for the Sprint may no longer address the biggest cause of customer drop-off. The Product Owner, who is available during the Sprint, has new customer evidence that supports this concern. The Sprint Goal is “Reduce checkout abandonment.” What should the Product Owner do next?
Best answer: C
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The Product Owner should respond immediately by inspecting the new value evidence with the Developers and deciding whether Sprint work should be adapted. During the Sprint, the Product Owner remains available to clarify value and can renegotiate scope with the Developers, while Sprint cancellation is only for an obsolete Sprint Goal.
The key concept is empirical adaptation during the Sprint. The Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt their plan, but when they uncover a product-value issue, the Product Owner should be available to inspect the new evidence with them promptly. If the Sprint Goal still provides value, the Product Owner and Developers can renegotiate the selected Product Backlog items to better support that goal. If inspection shows the Sprint Goal itself has become obsolete, only then may the Product Owner cancel the Sprint. Waiting until the Sprint Review delays learning and adaptation, and directing task changes in the Daily Scrum oversteps the Product Owner’s accountability.
The Product Owner should collaborate quickly with the Developers outside the Daily Scrum to inspect the value issue and adapt Sprint work while the Sprint Goal remains viable.
Topic: Events, Artifacts, and Done for Product Ownership
A Product Owner finishes a Sprint Review for a subscription product. Stakeholders liked the new cancellation feature, but data from the Done Increment shows fewer customers used it than expected. Based on this, the Product Owner now believes the next release will likely happen later than the earlier forecast. What is the best way to communicate these Sprint Review findings?
Best answer: C
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The Product Owner should make the Sprint Review outcome transparent by sharing what value was actually learned, updating the forecast based on evidence, and clarifying how the Product Backlog will adapt next. Sprint Review is about inspecting the product outcome with stakeholders, not protecting certainty or reporting completion alone.
In Scrum, the Sprint Review is used to inspect the outcome of the Sprint and determine future adaptations. The Product Owner should communicate what the Done Increment revealed about value, how that changes expectations, and what this means for the Product Backlog going forward. If new evidence suggests a later release, that should be shared openly as an updated forecast, not hidden until certainty exists.
Transparency is preserved when the Product Owner:
Focusing only on completed work misses the purpose of the Sprint Review, and handing backlog ordering to stakeholders breaks Product Owner accountability.
This preserves transparency by communicating actual value learned, an updated forecast rather than a promise, and the likely next steps for the product.
Topic: Product Owner and Backlog Management
A Product Owner is ordering a Product Backlog for a claims portal with this Product Goal: increase successful self-service claim completion. Three stakeholders disagree on what should be next. Sales wants a quote-sharing feature for one prospect, Support wants simpler password reset because 28% of calls are about login access, and Compliance wants audit-log improvements before a regulation takes effect in three months. What is the next best step for the Product Owner?
Best answer: D
What this tests: Product Owner and Backlog Management
Explanation: The Product Owner remains accountable for Product Backlog ordering, but should collaborate with stakeholders to inspect evidence, risks, and Product Goal alignment. In this situation, the best next step is to use that input transparently and then make the ordering decision.
This question tests Product Owner accountability in the face of conflicting stakeholder input. Stakeholders should provide context, evidence, constraints, and feedback, but they do not take over ordering decisions. Here, the Product Owner already has useful inputs: a Product Goal, support-call data, an uncertain sales request, and a known compliance deadline. The right next step is to bring those facts into a transparent discussion, inspect value, risk, and learning, and then reorder the Product Backlog accordingly.
That sequence fits Scrum’s empirical approach:
The closest traps either hand off Product Owner accountability or delay adaptation without a good reason.
This preserves Product Owner accountability for ordering while inviting stakeholder collaboration around value, risk, and Product Goal contribution.
Topic: Managing Products with Agility
A Scrum Team is working toward a Product Goal of reducing support calls through better self-service. In the Sprint Review, stakeholders inspect a Done Increment that adds searchable help articles. Usage increased, but support data shows most calls are still about account lockouts. Customers and the support lead suggest prioritizing self-service account recovery next, while a sales manager asks for cosmetic branding changes. What is the best implication of this Sprint Review outcome?
Best answer: C
What this tests: Managing Products with Agility
Explanation: The Sprint Review is a working session where the Scrum Team and stakeholders inspect the Sprint outcome and decide what to adapt next. Here, the evidence about support-call causes should inform Product Backlog ordering and any forecast changes needed to better progress toward the Product Goal.
A Sprint Review is not a sign-off meeting or a simple demonstration. Its purpose is to inspect the outcome of the Sprint with stakeholders and determine future adaptations based on what was learned. In this scenario, the new help articles produced some value, but the data shows the main customer problem is still account lockouts. That makes the review outcome actionable: the Product Backlog should be adapted to reflect the most valuable next step, and any release expectations may need to change.
The closest distractors treat the Sprint Review as approval, reporting, or a fixed-plan checkpoint, which is not its Scrum purpose.
The Sprint Review is for inspecting the Sprint outcome with stakeholders and deciding adaptations that best advance the Product Goal.
Topic: Developing People and Teams: Self-Managing Teams
An operations director who funds the product starts telling Developers during the Sprint which defects and features to do next. The Product Owner believes some requests may be valuable, but evidence is limited and the current Sprint Goal could be disrupted. The Developers are unsure whose direction to follow. Which response best fits Scrum?
Best answer: C
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: External authority can provide input, but it does not replace Scrum accountabilities. The Product Owner remains accountable for value and Product Backlog management, Developers remain self-managing for the Sprint plan, and the Scrum Master helps everyone understand and respect those boundaries.
When organizational pressure creates confusion, the Scrum Team should not solve it by shifting accountabilities to the loudest stakeholder. The Product Owner remains accountable for maximizing value and for effective Product Backlog management, so external requests must be evaluated and ordered through that accountability. The Developers remain accountable for their Sprint plan and for deciding how to turn selected work into a Done Increment. The Scrum Master helps the Scrum Team and stakeholders understand Scrum, including why funding authority or seniority does not give someone direct control over Developers’ work.
If the request matters, the Product Owner and Developers can inspect its impact on the Sprint Goal and adapt transparently. The key is preserving collaboration without breaking accountability boundaries.
This keeps value decisions with the Product Owner, Sprint execution with the Developers, and accountability clarification with the Scrum Master.
Topic: Developing People and Teams: Self-Managing Teams
A Scrum Team’s Product Goal is to reduce checkout abandonment. At the Sprint Review, a Done Increment shows mobile conversion improved 6% after guest checkout was added, but support feedback shows many mobile users still abandon at the address form. A sales stakeholder asks for a coupon feature before a campaign in three weeks. Which Product Owner action best supports self-management while keeping product decisions transparent?
Best answer: B
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The Product Owner is accountable for Product Backlog ordering and should use evidence tied to the Product Goal to make that order transparent. Developers remain self-managing by deciding how to turn selected work into a Done Increment.
This situation calls for the Product Owner to inspect the evidence from the Done Increment and stakeholder input, then adapt the Product Backlog order in a transparent way. The Product Goal is reducing checkout abandonment, and the latest evidence points to mobile address entry as the more direct value opportunity. A good Product Owner makes that ordering rationale visible to stakeholders and collaborates with Developers without directing their work.
The closest distraction is trying to satisfy everyone at once, but that weakens focus and crosses into directing Developers’ work.
This keeps Product Backlog ordering and value decisions transparent with the Product Owner while preserving Developers’ self-management over how to do the work.
Topic: Product Owner and Backlog Management
A Product Owner delegates much of the day-to-day Product Backlog work to a business analyst. After several Sprints, stakeholders see conflicting priorities, Product Backlog items are hard to compare, and some high-ranked items do not clearly support the Product Goal. Which concept best matches what is missing?
Best answer: A
What this tests: Product Owner and Backlog Management
Explanation: The issue is not that backlog work was delegated, but that the Product Owner is no longer ensuring an effective Product Backlog. In Scrum, the Product Owner remains accountable for its transparency, ordering, and alignment to the Product Goal even when others help with the work.
This situation points to Product Owner accountability for effective Product Backlog management. Scrum allows the Product Owner to delegate work related to Product Backlog management, but accountability does not transfer. If stakeholders see conflicting priorities, items are difficult to compare, and ordered work does not clearly support the Product Goal, the Product Backlog is not providing enough transparency or coherent ordering.
The Product Owner is accountable for ensuring that:
The key takeaway is that delegation can help with backlog work, but the Product Owner must still ensure clarity, ordering, and Product Goal alignment.
Delegation is allowed, but the Product Owner remains accountable for transparency, ordering, and Product Goal alignment in the Product Backlog.
Topic: Understanding and Applying the Scrum Framework
During a Sprint Review, a sales director tells the Scrum Team: “This customer feature must be next. Scrum Master, move it to the top of the backlog, and Developers, commit to delivering it in the next Sprint.” Which response is best?
Best answer: A
What this tests: Understanding and Applying the Scrum Framework
Explanation: The best response preserves Scrum Team accountabilities. The Product Owner remains accountable for maximizing value through Product Backlog ordering, Developers decide what can be Done in the Sprint, and the Scrum Master supports Scrum effectiveness rather than making product decisions.
This scenario tests clear accountability boundaries inside the Scrum Team. A stakeholder can provide important input, but cannot assign Product Backlog order through the Scrum Master or force Developers to make a delivery commitment. The Product Owner is accountable for maximizing product value and for effective Product Backlog management, so ordering remains with that accountability. Developers are accountable for creating a Done Increment and determining what can be accomplished in the Sprint. The Scrum Master is accountable for the Scrum Team’s effectiveness and helps everyone understand and apply Scrum correctly.
The strongest response does three things:
The closest distractors confuse expertise or urgency with accountability.
This keeps Product Backlog ordering with the Product Owner, delivery planning with Developers, and Scrum coaching with the Scrum Master.
Topic: Managing Products with Agility
A Product Owner for an online lending product has the Product Goal: “Increase successful self-service loan applications.” At the Sprint Review, the latest Done Increment showed a 2% improvement overall, but 18% of applicants still abandon during identity verification. A compliance lead also reports that a partner bank now requires multi-factor authentication before launch in 6 weeks.
Exhibit: Top of current Product Backlog
1. New dashboard theme
2. Export application history
3. Improve identity verification flow
4. Multi-factor authentication for partner bank
5. Contextual help tips
The next Sprint has not started. What is the best Product Owner response?
Best answer: A
What this tests: Managing Products with Agility
Explanation: When business priorities shift, the Product Owner adapts the Product Backlog based on the latest evidence, risks, and value considerations. Transparency means making the order and any revised forecast visible, not freezing the backlog or turning a forecast into a promise.
The Product Backlog is an emergent, ordered list of what is needed to improve the product, and the Product Owner is accountable for its effective management. In this scenario, new evidence from the Done Increment and a new compliance constraint both affect value, risk, and urgency. The best response is to reorder the Product Backlog accordingly and make that reasoning transparent to stakeholders.
This preserves empiricism:
Transparency does not require waiting for exhaustive detail, and stakeholder input does not transfer Product Owner accountability. The closest trap is treating the 6-week need as a delivery commitment rather than an updated forecast under uncertainty.
The Product Owner should empirically reorder the Product Backlog using the new value and risk information, while keeping the resulting order and forecast transparent.
Topic: Understanding and Applying the Scrum Framework
A Scrum Team ends a Sprint with these results:
Which interpretation is most consistent with Scrum?
Best answer: A
What this tests: Understanding and Applying the Scrum Framework
Explanation: In Scrum, work is part of the Increment only when it meets the Definition of Done. A successful demonstration, stakeholder enthusiasm, partial testing, or plans to finish later do not change that quality standard.
The key concept is that a Done Increment must be usable and meet the Definition of Done. In this scenario, Feature A is the only item that clearly satisfies that standard. Feature B was demonstrated and informally welcomed by stakeholders, but it still has required work remaining, so it is not Done. Feature C is also not Done because it is not yet integrated, even though some testing occurred. Scrum uses the Definition of Done to create transparency about actual progress, so unfinished work should not be treated as part of the Increment or as completed value. The closest distractors confuse visibility or approval with completeness, but Scrum distinguishes demonstrated or partially completed work from truly Done work.
A usable Increment consists only of work that meets the Definition of Done; informal approval, a demo, or partial testing do not make work Done.
Topic: Product Owner and Backlog Management
At a Sprint Review, a sales executive pressures the Product Owner to put a custom reporting feature at the top of the Product Backlog for one prospect. The Product Goal is to reduce onboarding time for self-service customers, and current evidence shows growth is coming mainly from that segment. The reporting feature would consume most of the next Sprint and does not help onboarding. What is the best response by the Product Owner?
Best answer: B
What this tests: Product Owner and Backlog Management
Explanation: The Product Owner is accountable for maximizing product value and for effective Product Backlog management. Stakeholder input matters, but backlog ordering should stay aligned to the Product Goal unless evidence indicates that changing direction would better maximize value.
This situation tests Product Owner accountability under stakeholder pressure. The Product Goal provides the long-term direction for the Product Backlog, so a request that conflicts with that direction should not be promoted simply because it comes from an influential stakeholder. The Product Owner should make the trade-off transparent, consider the request with available evidence, and keep the backlog ordered to best maximize value.
Stakeholder collaboration is important, but it does not transfer ordering accountability. Developers also do not decide product priority, and a Sprint is never something the Product Owner should promise in advance as a scope commitment. The key takeaway is that the Product Goal helps the Product Owner say “not now” or “not this way” when pressure conflicts with value evidence.
The Product Owner remains accountable for Product Backlog ordering and should use the Product Goal and evidence, not stakeholder pressure alone, to maximize value.
Topic: Understanding and Applying the Scrum Framework
A Sprint is ending for an online checkout product. The Scrum Team has a Done Increment, and test-user data from this Sprint shows checkout completion dropped compared with the current live flow. Several stakeholders have sent conflicting ideas about what to change next. What is the next most appropriate step?
Best answer: C
What this tests: Understanding and Applying the Scrum Framework
Explanation: With a Done Increment, outcome data, and stakeholder input, the next step is the Sprint Review. That event exists to inspect the Sprint’s result and determine what to adapt next, typically leading to Product Backlog changes.
Scrum provides regular opportunities to inspect and adapt instead of reacting informally. Here, the product outcome is ready to inspect: there is a usable Increment, evidence from users, and stakeholder feedback. The next step is the Sprint Review, where the Scrum Team and stakeholders inspect what was achieved during the Sprint and discuss future adaptations. The Product Owner can then adapt the Product Backlog to maximize value.
The closest trap is using the Retrospective for product priority decisions, which confuses product inspection with team improvement.
The Sprint Review is the event for inspecting the outcome of the Sprint with stakeholders and determining future Product Backlog adaptations.
Topic: Managing Products with Agility
A Product Owner for an invoicing product has this Product Goal: reduce invoice disputes for midsize customers. At the Sprint Review, the Scrum Team learns:
What should the Product Owner order first in the Product Backlog?
Best answer: B
What this tests: Managing Products with Agility
Explanation: The best choice uses customer feedback, support data, and a compliance constraint to inform Product Backlog ordering while keeping accountability with the Product Owner. It targets the clearest evidence of value and Product Goal progress, while reducing legal risk and creating learning from the next Increment.
Stakeholders and customers should provide feedback, constraints, domain insight, and value evidence that inform Product Owner decisions. In this case, the strongest evidence is the support data and customer feedback showing a major source of disputes, which directly relates to the Product Goal. The compliance input is also important, but it is a constraint to respect, not a handoff of ordering authority.
A sales request may still matter, but it is weaker than evidence pointing to the most important current value problem.
It uses customer evidence and stakeholder constraints to inform ordering while preserving the Product Owner’s accountability for maximizing value.
Topic: Events, Artifacts, and Done for Product Ownership
At a Sprint Review, the Scrum Team shows a feature that customers like. However, required security checks in the Definition of Done are still incomplete. Several stakeholders ask the Product Owner to count the feature as delivered value in the quarterly update because it is “almost finished.” What is the best response?
Best answer: B
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The Product Owner should preserve transparency around the Increment and the Definition of Done. If required Done work is incomplete, the feature is not a Done Increment and should not be counted as delivered value. Progress can still be shared honestly as unfinished work and a forecast.
In Scrum, delivered product value comes from a usable Increment that meets the Definition of Done. If required security checks are incomplete, the work is not Done, so the Product Owner should not report it as delivered value or treat it as releasable. The better response is to stay transparent: show the progress, explain what remains, and communicate any release expectation as a forecast rather than a fact.
The closest trap is counting “almost finished” work as value just because stakeholders are applying pressure.
Only a Done Increment should be treated as delivered value; unfinished work can be discussed transparently but not counted as delivered.
Topic: Understanding and Applying the Scrum Framework
During a Sprint, the Scrum Team discovers that its current Definition of Done does not satisfy the product’s security needs and is below a newly clarified organizational quality standard. Which action best aligns with Scrum?
Best answer: D
What this tests: Understanding and Applying the Scrum Framework
Explanation: When the current Definition of Done no longer meets product or organizational quality needs, the response is to improve that quality commitment. The Scrum Team should use the stronger standard to increase transparency, and any effect on scope or forecast should be handled openly.
The Definition of Done is the commitment for the Increment and creates transparency about quality. If the Scrum Team learns that its current Definition of Done is too weak for the product or does not meet organizational standards, the right action is to strengthen it rather than work around it. Organizational standards are a minimum; if the product needs more, the Scrum Team should reflect that in the Definition of Done.
Developers must conform to the Definition of Done when creating Increments. A Product Owner may then adapt Product Backlog ordering or forecasts based on the clearer quality reality, but cannot waive the standard for selected items. Adding extra gates or postponing the change hides quality problems instead of making them transparent.
The Definition of Done is the Increment’s quality commitment, so it should be strengthened when it no longer meets needed standards.
Topic: Managing Products with Agility
During a Sprint Review, a Scrum Team demonstrates a Done Increment for faster customer onboarding. Feedback from pilot customers shows their bigger need is audit reporting, which weakens the Product Owner’s current Product Goal of reducing setup time. A sales leader also asks for audit reporting before a large prospect meeting next month. Sprint Planning is tomorrow. What is the best Product Owner action?
Best answer: B
What this tests: Managing Products with Agility
Explanation: Sprint Review feedback should be used to inspect product progress and adapt based on new evidence. When feedback reveals a changed customer need or a risk to the current Product Goal, the Product Owner should transparently reassess direction and reorder the Product Backlog before the next Sprint.
The key concept is empirical product adaptation. The Sprint Review is where the Scrum Team and stakeholders inspect the outcome of the Sprint and determine future adaptations. Here, customer feedback directly challenges the current value assumption behind the Product Goal, so the Product Owner should not simply continue the existing plan. The Product Owner remains accountable for maximizing value and for effective Product Backlog management, including ordering and clarifying product direction.
A strong response is to use the new evidence to:
Urgent stakeholder input matters, but it does not replace evidence or transfer accountability. The closest trap is treating the loudest request as the new priority without first integrating it into a transparent product decision.
This uses Sprint Review evidence to adapt product direction while preserving the Product Owner’s accountability for value and Product Backlog management.
Topic: Managing Products with Agility
A Product Owner sees that a newly released feature is Done and used by customers, but the expected business outcome has not improved. Which action best improves learning about value?
Best answer: A
What this tests: Managing Products with Agility
Explanation: When output is delivered but outcomes do not improve, the Product Owner should learn from evidence and adapt. Inspecting actual value signals with stakeholders and then reordering the Product Backlog supports empiricism and value maximization.
The core idea is learning over output. A Done Increment creates transparency about what was delivered, but it does not prove that value was achieved. When expected outcomes are missing, the Product Owner should inspect outcome evidence such as customer behavior, stakeholder feedback, or business results, and then adapt Product Backlog ordering to improve future value.
This fits Scrum because:
Adding more features without learning may increase output but not value. Treating “Done” as proof of success confuses delivery with outcome. Handing ordering to stakeholders breaks Product Owner accountability. The best choice preserves accountability and uses empiricism to improve value decisions.
This uses evidence and stakeholder feedback to inspect value and adapt toward better outcomes while keeping Product Owner accountability.
Topic: Product Owner and Backlog Management
A Product Owner for an online learning product has a broad product vision: “Become the easiest way for small businesses to train employees.” After several Sprints, the Product Backlog contains many unrelated requests from sales, support, and compliance. In the latest Sprint Review, stakeholders disagreed on priorities, and the Developers said the backlog lacks a clear longer-term direction. What should the Product Owner do next?
Best answer: A
What this tests: Product Owner and Backlog Management
Explanation: The missing element is a Product Goal. The vision is too broad, while the backlog needs a concrete long-term objective that helps the Product Owner order work coherently and align stakeholder input.
A Product Goal is the commitment for the Product Backlog and provides the Scrum Team with a clear long-term objective. In this scenario, the product vision already exists, but it is too broad to guide day-to-day Product Backlog ordering. The next appropriate step is to clarify a Product Goal and use it to bring coherence to the backlog.
A Sprint Goal would only guide a single Sprint, not the longer-term direction the team says is missing. A release plan can be useful as a forecast, but it does not replace the Product Goal. Individual stakeholder requests are inputs, not the product direction by themselves.
The key distinction is that the Product Goal connects the broad vision to the ordered Product Backlog.
A Product Goal gives the Product Backlog a coherent long-term objective, which is the missing next step in this situation.
Topic: Product Owner and Backlog Management
A Product Owner tells stakeholders that new requests will be evaluated by how much they help the product’s long-term target. The Product Backlog is ordered to improve progress toward that target, and requests that do not help may be deferred. Which Scrum term best matches that long-term target?
Best answer: D
What this tests: Product Owner and Backlog Management
Explanation: This describes the Product Goal. In Scrum, the Product Goal is the long-term objective for the Scrum Team and the commitment for the Product Backlog, so it should guide ordering, stakeholder communication, and decisions about incoming requests.
The key concept is the Product Goal. It gives the Scrum Team a coherent long-term objective and provides a basis for ordering the Product Backlog around progress toward that objective. When stakeholders suggest new work, the Product Owner should consider whether it supports, changes, or distracts from the current Product Goal, then communicate those tradeoffs transparently.
A Sprint Goal is only for a single Sprint, while the Definition of Done is a quality commitment for the Increment. A product vision may exist as broader direction, but in Scrum the Product Goal is the specific commitment tied to the Product Backlog. That is why it is the best match for using progress to guide backlog decisions and stakeholder conversations.
The Product Goal is the long-term objective that guides Product Backlog ordering and helps the Product Owner assess new requests.
Topic: Developing People and Teams: Self-Managing Teams
Halfway through a Sprint, the board shows the Product Backlog item most tied to the Sprint Goal is blocked, while two lower-value items are still in progress. A stakeholder asks the Product Owner to direct the Developers to switch work immediately. What is the best response?
Best answer: D
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The Product Owner is accountable for maximizing value, but the Developers are accountable for managing the Sprint Backlog during the Sprint. The best response is to clarify the value implications and let the Developers decide how to adapt their plan toward the Sprint Goal.
This scenario tests a common Scrum trap: confusing Product Owner accountability with directing the Developers’ work. The Product Owner remains accountable for maximizing product value and can clarify which outcome matters most, especially when stakeholder pressure appears. However, the Sprint Backlog belongs to the Developers, and they adapt it as needed during the Sprint.
The board provides transparency about the current state of work, but it does not give the Product Owner authority to assign work or manage the Developers’ plan. Likewise, selected Sprint work is not a fixed scope contract, and work is not complete unless it meets the Definition of Done. The right response is collaboration on value and trade-offs, while preserving Developer self-management.
The Product Owner clarifies value and priorities, while the Developers decide how to adjust their Sprint plan.
Topic: Managing Products with Agility
A Product Owner is asked for a release forecast after a Sprint Review. Two Product Backlog items are Done and already in customer use. Four other items are partially built but not Done. New feedback moved a compliance item to the top of the Product Backlog, replacing a lower-value feature previously assumed in the release. Sales still wants the original launch date announced today. Which response by the Product Owner is most appropriate?
Best answer: C
What this tests: Managing Products with Agility
Explanation: The best response is to base the release forecast on what is actually Done and on the current Product Backlog order. Because unfinished work and changed ordering increase uncertainty, the Product Owner should communicate a forecast transparently rather than present the old date as reliable.
In Scrum, a release forecast is only as reliable as the evidence behind it. Here, partially built items are not Done, so they are not usable empirical evidence. Also, stakeholder feedback changed Product Backlog order by moving a compliance item to the top, which changes both likely scope and timing for any release expectation. The Product Owner remains accountable for making value-focused decisions and for communicating uncertainty clearly.
A sound approach is to:
Keeping the original date may feel reassuring, but it hides risk instead of making it transparent.
A reliable Scrum forecast uses empirical evidence from Done Increments and the current ordered Product Backlog, while making uncertainty transparent.
Topic: Understanding and Applying the Scrum Framework
A large customer tells the Product Owner: “We need the new export feature in the next Sprint. Please tell the Developers to pause the refactoring work and assign two people to this item so sales can promise delivery.” Which Product Owner response is best?
Best answer: B
What this tests: Understanding and Applying the Scrum Framework
Explanation: The Product Owner should use stakeholder input to maximize value and manage the Product Backlog, but should not direct how Developers perform the work. A transparent forecast is appropriate; a delivery promise or task assignment is not.
The core concept is balancing Product Owner accountability with Developers’ self-management. The customer’s request is valuable input, so the Product Owner should consider it when ordering the Product Backlog and when discussing why a Sprint would be valuable. However, the Product Owner should not assign people or direct the technical approach, because Developers decide how to turn selected work into a Done Increment.
A good response also avoids false certainty. In Scrum, what will be delivered in a Sprint is a forecast created through collaboration in Sprint Planning, not a promise made under stakeholder pressure. The strongest response therefore accepts the input, preserves Product Owner accountability for Product Backlog effectiveness and value, respects Developers’ autonomy, and communicates any forecast transparently.
The closest distractor is the one that moves the item to the top, but it fails because it also overrides self-management by assigning Developers.
This keeps Product Backlog accountability with the Product Owner, uses stakeholder input, and respects Developers’ self-management over how work is done.
Topic: Developing People and Teams: Self-Managing Teams
After a Sprint Review, a sales director messages the Product Owner: “A major prospect may buy if we can show six requested features at a conference in 8 weeks. Please lock the backlog now, have someone assign the work daily, and send me a firm commitment.” Which response is best?
Best answer: A
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The best response is transparent and empirical. It gives the stakeholder a forecast based on evidence, keeps Product Backlog decisions with the Product Owner, and avoids directing how Developers do their work.
This scenario mixes three common Scrum traps: treating a forecast like a commitment, bypassing Product Owner accountability, and undermining Developers’ self-management. A good response should help the stakeholder make a decision without pretending uncertainty is gone. The Product Owner remains accountable for effective Product Backlog management, including ordering to maximize value, while Developers decide how to turn selected work into a Done Increment.
Using the current Product Backlog and completed Increments supports empiricism because it relies on visible evidence rather than pressure. Discussing which outcomes matter most for the conference also helps inspect and adapt scope as learning continues. The key takeaway is that Scrum responds to important opportunities with transparency and collaboration, not by freezing learning or centralizing control.
This keeps Product Backlog accountability with the Product Owner, preserves Developers’ self-management, and communicates an evidence-based forecast rather than a false certainty.
Topic: Managing Products with Agility
A Product Owner told stakeholders that a new reporting capability was likely to be released in about two months. At the Sprint Review, customers used the latest Done Increment and requested a critical export feature. In Product Backlog refinement, the Scrum Team learned that this feature is larger and riskier than expected. Stakeholders now ask whether the original date still stands.
What is the best Product Owner communication?
Best answer: D
What this tests: Managing Products with Agility
Explanation: The Product Owner should communicate transparently that the forecast has changed because new evidence emerged from inspection. In Scrum, forecasts are updated empirically; they are not fixed promises that override learning.
The key concept is the difference between a forecast and a commitment. After Sprint Review and refinement, the Product Owner has better evidence about customer needs, size, and risk. The right response is to make that change visible, explain why the forecast moved, and provide the best current outlook with appropriate uncertainty.
This supports empiricism:
Trying to preserve an outdated date would hide uncertainty and weaken trust. The Product Owner remains accountable for communicating value, ordering decisions, and realistic expectations as the product evolves.
A release forecast should be updated transparently when inspection reveals new information, because a forecast is not a commitment.
Topic: Managing Products with Agility
Stakeholders push for several new features, but data from recent Done Increments shows that simplifying onboarding would improve customer activation more than adding those features. The Product Owner reorders the Product Backlog toward onboarding improvements. Which Scrum accountability is most directly illustrated?
Best answer: A
What this tests: Managing Products with Agility
Explanation: This describes the Product Owner acting on evidence to pursue the more valuable product outcome, even when stakeholders ask for more output. In Scrum, the Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team’s work.
The key idea is value over feature volume. When stakeholder requests conflict with evidence from real product use, the Product Owner should use that evidence to guide Product Backlog ordering toward the outcome that is more valuable. That is a direct expression of the Product Owner’s accountability to maximize product value.
In this case, the Product Owner is not just collecting requests; they are making a value decision based on learning from Done Increments. Scrum supports this through empiricism: inspect actual results, then adapt the Product Backlog. Stakeholders provide important input, but they do not take over ordering decisions.
The takeaway is that more requested features are not automatically the best choice if evidence points to a better outcome.
The Product Owner is using evidence to choose the option expected to create more value, which is central to this accountability.
Topic: Product Owner and Backlog Management
A Product Owner is ordering the Product Backlog for a product whose Product Goal is to let customers manage their own subscriptions. Customer feedback shows that self-service plan changes would reduce support calls significantly. However, the highest-value item depends on a third-party billing API with unclear limits, and a senior stakeholder is pressing for a cosmetic dashboard change before an upcoming demo.
What is the best ordering decision?
Best answer: B
What this tests: Product Owner and Backlog Management
Explanation: The best choice balances value with uncertainty. When a high-value item carries meaningful technical or dependency risk, the Product Owner can order learning work first so the Scrum Team gains evidence and can improve later backlog decisions.
Product Backlog ordering is not only about headline value; it also considers risk, dependency uncertainty, and learning that improves future value decisions. In this case, the self-service change clearly supports the Product Goal, but the unclear billing API limits create a real risk to delivery and usefulness. Ordering a small learning-focused item first is a sound Product Owner decision because it helps the Scrum Team inspect uncertainty early and adapt based on what they discover.
This approach helps the Product Owner:
The closest distractor is keeping the high-value item first unchanged, but that ignores the need to learn enough to order effectively under uncertainty.
This preserves focus on the highest-value outcome while reducing uncertainty early so later ordering can be based on evidence.
Topic: Developing People and Teams: Self-Managing Teams
A Product Owner for an e-commerce product has a Product Goal: reduce cart abandonment by 15% in six months. In Sprint Planning, a sales leader says, “The Sprint Goal is deliver coupons, analytics, and payment fixes for the trade show.” A Developer adds, “If testing slips, we can still call it Done and finish testing next Sprint.” The Product Owner then starts assigning daily work from the Sprint Backlog. Which response best resolves these Scrum misunderstandings?
Best answer: B
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The best response is to re-establish the correct Scrum artifacts, commitments, and accountabilities. The Product Goal guides long-term direction, the Sprint Goal gives one Sprint objective, the Definition of Done cannot be weakened to protect optics, and Developers manage the Sprint Backlog while the Product Owner remains accountable for Product Backlog ordering.
This scenario mixes up several Scrum terms at once. The Product Goal is the long-term objective for the product, not a list of features or a trade-show delivery plan. The Sprint Goal is a single objective for the Sprint, not the full bundle of requested scope. The Definition of Done is the quality commitment for the Increment, so work that still needs testing is not Done. The Product Owner is accountable for effective Product Backlog management, including ordering based on value, risk, and learning from stakeholder input. Developers, as a self-managing part of the Scrum Team, create and adapt the Sprint Backlog and decide how to do the work.
The closest distractors either chase urgency, certainty, or output, but they do so by breaking Scrum transparency or accountability.
This option correctly separates the long-term Product Goal, the Sprint Goal, the Definition of Done, and the distinct accountabilities for Product Backlog ordering and Sprint Backlog management.
Topic: Developing People and Teams: Self-Managing Teams
A Product Owner notices that Developers have started working in separate UI, API, and testing lanes. At Sprint Reviews, several Product Backlog items are partly completed in one lane but not Done end-to-end, and a manager suggests appointing technical leads for each lane. To improve delivery of usable Increments, what is the next appropriate step?
Best answer: D
What this tests: Developing People and Teams: Self-Managing Teams
Explanation: The Scrum Team should stay cross-functional and self-managing, without specialist sub-teams or internal hierarchies. Since partially completed component work is blocking Done Increments, the best next step is to refine work into end-to-end slices that Developers can complete together.
The issue is not that people have different skills; it is that work is being structured around specialties instead of end-to-end value. In Scrum, the Scrum Team has no sub-teams or hierarchies, and the Developers are collectively accountable for creating a Done Increment each Sprint. A good next step is for the Product Owner to collaborate with Developers on Product Backlog refinement so items are more transparent as customer-valuable, end-to-end slices.
That supports Developers in planning and collaborating across skills as one Scrum Team. It avoids reinforcing handoffs, waiting, and partially finished component work. Adding leads, sub-teams, or an extra integration Sprint would preserve or worsen the current problem instead of improving cross-functionality and usable delivery.
This promotes cross-functional collaboration around usable value without creating sub-teams or hierarchy inside the Scrum Team.
Topic: Managing Products with Agility
A Product Owner reviews the latest Sprint outcome for an online subscription product:
Which metric is primarily an activity or output measure rather than evidence of customer or business value?
Best answer: D
What this tests: Managing Products with Agility
Explanation: The count of finished Product Backlog items is an output metric. It says how much work was completed, but not whether the product created better customer outcomes or improved business results.
PSPO I emphasizes maximizing value, so the Product Owner should prefer evidence of outcomes over measures of activity. Conversion rate, signup time, and support-ticket reduction all indicate a change in customer behavior, customer experience, or business performance. Those are value signals because they help show whether the product is solving a real problem and improving results.
By contrast, the number of Product Backlog items completed only reflects output volume. A Scrum Team can finish many items without increasing adoption, satisfaction, revenue, or other meaningful outcomes. In Scrum, a Done Increment creates transparency, but value still needs to be inspected through evidence such as customer feedback and business impact.
A high output count may support delivery forecasting, but it is not itself proof of value.
Counting completed Product Backlog items shows output volume, not whether customers or the business received more value.
Topic: Events, Artifacts, and Done for Product Ownership
At the end of a Sprint, Developers have finished coding a high-value feature, but automated tests and a required security check are still incomplete. The Scrum Team’s Definition of Done requires both before work can be considered part of the Increment. Two stakeholders ask the Product Owner to count the feature as delivered value in the quarterly report because “it is 90% done” and looked good in a demo. What is the best response?
Best answer: B
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The Product Owner should preserve transparency by treating only Done work as delivered value. If the feature does not meet the Definition of Done, it is not part of a usable Increment, so reporting it as delivered would misrepresent progress and value.
In Scrum, delivered value should be based on a usable Increment that meets the Definition of Done. The scenario makes the deciding fact explicit: required testing and security checks are incomplete, so the feature is not Done. The Product Owner is accountable for maximizing value, but that does not allow redefining unfinished work as delivered value.
The best response is to keep the actual state transparent:
A demo of incomplete work may provide useful feedback, but it is not the same as a Done Increment. Calling partial work delivered weakens transparency and undermines empirical decision-making.
Only a Done Increment provides transparent evidence of delivered value; partial work remains unfinished and should not be reported as delivered.
Topic: Managing Products with Agility
A product steering group meets weekly, votes on Product Backlog order, and tells Developers which requests must be worked on next. The Product Owner is expected to record the committee’s decisions rather than make them. Which concept best matches this situation?
Best answer: C
What this tests: Managing Products with Agility
Explanation: This is command-and-control governance because stakeholders are directing Product Backlog order and team work instead of collaborating with the Product Owner. In Scrum, stakeholders provide input, but the Product Owner remains accountable for Product Backlog decisions.
The core concept is preserving Product Owner accountability while engaging stakeholders for input and feedback. In the scenario, the steering group is not simply collaborating; it is making priority decisions and directing work, which turns stakeholder engagement into command-and-control governance. That undermines Scrum’s empirical approach, where the Product Owner uses evidence, feedback, and Product Goal alignment to order the Product Backlog.
Stakeholders should inform decisions, not replace the accountable decision-maker. Developers also should not be directed by an external committee on what to work on next. The key takeaway is that collaboration supports transparency and learning, while command-and-control removes accountability and reduces adaptation to evidence.
This replaces Product Owner accountability and empirical learning with stakeholder control over decisions and work direction.
Topic: Events, Artifacts, and Done for Product Ownership
Mid-Sprint, a Product Owner is attending the Daily Scrum because two selected Product Backlog items need occasional clarification. After several days, the event has become a 20-minute status meeting for the Product Owner, and the Developers are no longer updating their plan toward the Sprint Goal during it. A stakeholder also wants daily progress updates. What is the best action for the Product Owner?
Best answer: A
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The best action is to stop treating the Daily Scrum as a status meeting and preserve its purpose for the Developers. The Product Owner should remain available for clarification during the Sprint, but the Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed.
The core concept is the boundary and purpose of the Daily Scrum. It is an event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, especially their plan for the next day of work. The Product Owner may be available during the Sprint to answer questions or clarify Product Backlog items, but that does not change ownership of the Daily Scrum.
In this scenario, the problem is not Product Owner availability; it is that the event has drifted into a reporting session. A better approach is for the Product Owner to provide clarification outside the Daily Scrum or only when helpful without changing the event into a status meeting. That preserves transparency and supports self-management by the Developers.
The key takeaway is that stakeholder reporting and Product Owner coordination must not replace the Developers’ daily inspection and adaptation around the Sprint Goal.
The Daily Scrum belongs to the Developers, and its purpose is to inspect progress toward the Sprint Goal and adjust their Sprint Backlog plan.
Topic: Understanding and Applying the Scrum Framework
A Product Owner presents a release forecast as certain, avoids surfacing conflicting stakeholder priorities, and leaves important Product Backlog items intentionally vague to reduce debate. Which Scrum concept is being undermined most directly?
Best answer: A
What this tests: Understanding and Applying the Scrum Framework
Explanation: This behavior most directly violates openness. In Scrum, openness means making work, uncertainty, and concerns transparent so the Scrum Team and stakeholders can inspect reality and adapt based on evidence.
The core concept is the Scrum value of openness. A Product Owner supports openness by making uncertainty visible, exposing conflicting stakeholder needs, clarifying Product Backlog ambiguity, and being transparent about weak value evidence. Hiding those things reduces transparency and prevents effective inspection and adaptation, which undermines empiricism.
In this situation, the problem is not mainly about losing concentration on one objective, failing to honor a promise, or treating people poorly. The central issue is that key product information is being concealed from the people who need it to make sound decisions.
The key takeaway is that Product Owners maximize value better when they make reality visible, even when that reality is inconvenient.
Openness is weakened because uncertainty, conflict, and ambiguity are being hidden instead of made transparent for inspection and adaptation.
Topic: Events, Artifacts, and Done for Product Ownership
During Sprint Planning for an online store, the draft Sprint Goal is: “Add saved carts, fix checkout address validation, update tax rules, and improve page speed.” A stakeholder asks the Product Owner to send that wording to leadership as the Sprint Goal. Which response from the Product Owner is best?
Best answer: C
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The draft wording is only a list of selected Product Backlog items, not a Sprint Goal. The best response reframes it as a single value-focused objective and keeps the item list in the Sprint Backlog as the forecast for achieving that objective.
A Sprint Goal is the single objective for the Sprint and explains why the Sprint is valuable. In this scenario, the proposed wording is just a list of work items, so it gives neither the Scrum Team nor leadership a clear value-based purpose. A better response is to express the intended customer or business outcome those items support, such as improving checkout completion, and leave the selected items in the Sprint Backlog.
This improves focus, supports inspection of progress toward one objective, and avoids presenting the Sprint as a fixed scope contract. The key distinction is that the Sprint Goal is the commitment for the Sprint Backlog, while the selected Product Backlog items are part of the forecast for meeting that goal.
A Sprint Goal should express the Sprint’s value objective, while the selected Product Backlog items remain the forecast in the Sprint Backlog.
Topic: Understanding and Applying the Scrum Framework
At Sprint Planning, the Scrum Team reviews feedback from the last Sprint Review: trial users still abandon signup at the payment step, while stakeholders are asking for new reporting features. The Developers ask the Product Owner what contribution would help most right now. Which action best supports Sprint Planning without taking over how the work will be done?
Best answer: D
What this tests: Understanding and Applying the Scrum Framework
Explanation: In Sprint Planning, the Product Owner contributes product value, Product Goal context, and clarity on the most important Product Backlog items. The Developers then decide how to turn selected work into a Done Increment and manage their own plan.
Sprint Planning answers why the Sprint is valuable, what can be Done this Sprint, and how the work will be accomplished. The Product Owner best supports this by clarifying the desired outcome, explaining the value of the highest ordered Product Backlog items, and helping the Scrum Team align on a useful Sprint Goal.
The key boundary is that the Product Owner supports value decisions, not the Developers’ detailed execution plan. The Developers are accountable for creating the plan for the Sprint and deciding how to do the work. A delivery promise for every selected item would also be inappropriate because the selected work is a forecast, while the Sprint Goal is the commitment.
The best Product Owner contribution combines value clarity with respect for self-management.
This gives the Developers value and ordering context for Sprint Planning while leaving tasking and technical planning to them.
Topic: Managing Products with Agility
A Product Owner reviews a proposed Product Backlog item by asking two questions: “Does this fit the product’s desired future direction?” and “Does it help achieve the current long-term objective?” Which concept matches the product’s desired future direction?
Best answer: A
What this tests: Managing Products with Agility
Explanation: The broader future direction for a product is its Product Vision. The Product Goal is the current long-term objective, so the description intentionally separates strategic direction from the nearer-term target the Scrum Team is pursuing.
A Product Vision expresses where the product is headed and why it exists, so it helps the Product Owner judge whether a proposed Product Backlog item fits the product’s broader direction. The Product Goal is different: it is the current long-term objective for the Scrum Team and the commitment for the Product Backlog. In the stem, the second question already describes the Product Goal, so the first question points to the Product Vision.
A useful check is:
The closest distractor is Product Goal, but that is the current target, not the overall direction.
Product Vision describes the broader future direction for the product, which helps judge strategic fit of a Product Backlog item.
Topic: Events, Artifacts, and Done for Product Ownership
During a Sprint Review, the Scrum Team inspects a Done Increment that adds a new onboarding flow. The Product Goal is to improve customer adoption. Sales says the change is valuable because enterprise prospects completed setup faster in a pilot, while Customer Support says existing customers found it confusing and mostly used the old flow. What is the best action for the Product Owner?
Best answer: A
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: When stakeholders disagree in Sprint Review, the Product Owner should use the Product Goal, the inspected Increment, and available evidence to decide how to adapt next. Stakeholder input matters, but Product Backlog ordering remains the Product Owner’s accountability.
The Sprint Review is for inspecting the outcome of the Sprint with stakeholders and determining future adaptations. Disagreement about value should not be resolved by vote, hierarchy, or technical convenience alone. The Product Owner is accountable for maximizing value and for effective Product Backlog management, so the best response is to examine the evidence from the Done Increment against the Product Goal, discuss the trade-offs transparently, and then adapt Product Backlog ordering.
In this case, the pilot suggests different value for different user groups, so the next step should be evidence-based learning or improvement aimed at customer adoption. The key is that stakeholders inform the decision, but they do not own Product Backlog ordering.
This preserves Product Owner accountability while using Sprint Review evidence and stakeholder feedback to guide adaptation.
Topic: Events, Artifacts, and Done for Product Ownership
During Sprint Planning for a payments product, the top-ordered Product Backlog item is a new partner export requested yesterday by a sales director for an upcoming demo. Developers say they can either start that item with a high risk of ending the Sprint with only partial work, or complete two slightly lower-ordered items that together support a clear Sprint Goal: reduce failed checkout retries for current customers. What is the best Product Owner action?
Best answer: D
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The Product Owner should collaborate with Developers on a Sprint Goal that makes the Sprint valuable and select Product Backlog items that support it. Backlog order matters, but it does not override the need for a coherent goal, a realistic forecast, and transparent communication about uncertainty.
Product Backlog order is important input to Sprint Planning, but the Sprint Goal is the commitment for the Sprint Backlog. The Product Owner and Developers should first determine why the Sprint is valuable, then select Product Backlog items that make achieving that goal likely.
In this scenario, the new export request is urgent but risky, and choosing it would likely produce partial work with no clear Sprint objective. The better choice is to collaborate on a coherent Sprint Goal around the items that can be Done and deliver current customer value, while being transparent with the sales director about the trade-off and forecast. The Product Owner keeps accountability for Product Backlog ordering; Developers provide feasibility and delivery insight.
The key takeaway is that Product Backlog order guides selection, but it should not force a weak Sprint Goal or hide uncertainty.
Sprint Planning should optimize Sprint value through one coherent Sprint Goal and a realistic forecast, while the Product Owner remains accountable for ordering and stakeholder communication.
Topic: Understanding and Applying the Scrum Framework
After a Sprint Review, a Product Owner receives conflicting input: Sales wants a referral feature next, a compliance manager says audit logging should move to the top due to a new regulation, and Developers recommend reducing integration complexity first to lower delivery risk. A senior manager proposes a weekly committee to set the Product Backlog order for the Product Owner. Which response best aligns with Scrum?
Best answer: B
What this tests: Understanding and Applying the Scrum Framework
Explanation: In Scrum, stakeholders, managers, and Developers can all provide valuable input, but they do not take over Product Backlog ordering. The Product Owner is the one person accountable for effective Product Backlog management and for maximizing product value.
The key concept is Product Owner accountability. Scrum encourages collaboration with stakeholders and Developers, especially when value, risk, and constraints conflict, but that collaboration does not transfer accountability for Product Backlog ordering. The Product Owner should use the available evidence, such as regulatory urgency, customer value, and delivery risk, to decide the order that best supports the Product Goal and maximizes value.
A committee may advise, Developers may highlight technical risk, and managers may raise business concerns, but none of them replaces the Product Owner’s accountability. The closest distractors confuse useful input with decision ownership. In Scrum, Product Backlog management can involve others, yet the Product Owner remains accountable for the result.
Scrum allows broad input, but the Product Owner remains the single person accountable for effective Product Backlog management and ordering.
Topic: Product Owner and Backlog Management
A Product Owner notices that the top of the Product Backlog now contains urgent stakeholder requests, technical experiments, and reporting enhancements. Recent Sprint Reviews show the strongest customer evidence still supports the current Product Goal: reducing onboarding abandonment for new users. Many of the new items do not clearly contribute to that goal. What should the Product Owner do next?
Best answer: B
What this tests: Product Owner and Backlog Management
Explanation: The Product Owner is accountable for effective Product Backlog management and for maximizing product value. When items no longer clearly support the current Product Goal, the best action is to re-evaluate ordering and transparency so the backlog again reflects coherent progress toward that goal.
A coherent Product Backlog should visibly support the current Product Goal. In this scenario, customer evidence still supports reducing onboarding abandonment, so the Product Owner should inspect the backlog against that goal and adapt it accordingly. That means collaborating with stakeholders and the Scrum Team as needed, but remaining accountable for ordering decisions, clarifying item purpose, and making tradeoffs transparent. Items without a clear contribution may be deprioritized, refined until their value is clearer, or removed. This balances value, evidence, learning, risk, and stakeholder impact without turning the backlog into a list of unrelated requests. The key takeaway is that Product Backlog variety is not the goal; coherence toward the Product Goal is.
This restores Product Backlog coherence by keeping ordering tied to the current Product Goal while using evidence and transparent tradeoffs.
Topic: Events, Artifacts, and Done for Product Ownership
A Scrum Team’s Product Goal is to reduce customer-support contacts for account access problems. In the Sprint Review, they inspect a Done Increment that adds clearer login error messages. Stakeholders also share new support data showing 70% of current contacts come from password reset failures, while early feedback on the new messages is positive but overall contact volume has not changed. What is the next appropriate step?
Best answer: C
What this tests: Events, Artifacts, and Done for Product Ownership
Explanation: The Sprint Review should create product learning that can drive adaptation. Here, the new evidence shows the larger problem is password reset failures, so the Product Owner should use that learning to re-order the Product Backlog and transparently update expectations about forecast and Product Goal progress.
A Sprint Review is used to inspect the outcome of the Sprint with stakeholders and determine future adaptations. In this case, the review generated actionable learning: the Increment helped a smaller issue, but current evidence shows password reset failures are the bigger driver of support contacts, and the Product Goal is not yet moving.
The appropriate next step is to use that evidence to adapt the Product Backlog order, refine upcoming work around the more valuable problem, and communicate any changed forecast based on what is now known. Forecasting in Scrum is empirical, not a promise, and Product Goal progress should be discussed using real results from Done Increments and stakeholder feedback.
The key takeaway is that useful Sprint Review learning should change product decisions when the evidence warrants it.
The Sprint Review produced actionable evidence about value and goal progress, so the Product Owner should adapt the Product Backlog and communicate revised expectations.
Topic: Managing Products with Agility
A Scrum Team’s Product Goal is to increase trial-to-paid conversion. At the Sprint Review, several customers report that onboarding is confusing, and usage data shows 40% of trial users abandon setup. The Product Backlog is currently ordered with a custom export feature at the top because the sales director wants it for one prospect. What is the Product Owner’s most appropriate next step?
Best answer: C
What this tests: Managing Products with Agility
Explanation: The Product Owner remains accountable for Product Backlog ordering, even when customer feedback conflicts with internal stakeholder preferences. The best next step is to inspect the new evidence, adapt the backlog toward the Product Goal, and communicate that decision transparently.
This situation calls for empiricism and Product Owner accountability. New customer feedback and usage data indicate that onboarding friction is a stronger value signal than a feature request for a single prospect, especially because the Product Goal is to improve trial-to-paid conversion. The Product Owner should use that evidence to refine and reorder the Product Backlog, then make the reasoning transparent to stakeholders.
The key is sequence: inspect the new evidence first, adapt the Product Backlog next, and then let Sprint Planning use the updated order. Internal stakeholders can provide input, but they do not control Product Backlog ordering. Developers may help with understanding options and tradeoffs, but they do not decide product value priority.
The closest distractor is keeping the old order for consensus, which weakens Product Owner accountability and slows adaptation.
The Product Owner should adapt Product Backlog ordering based on evidence and Product Goal alignment while remaining accountable for the decision.
Topic: Product Owner and Backlog Management
A Product Owner sees that Sprint Planning is tomorrow. The top Product Backlog items were written months ago, several are large and vague, and recent customer feedback may change what is most valuable. Developers say they cannot confidently discuss what can be Done, and stakeholders are asking why priorities changed. What is the best action?
Best answer: B
What this tests: Product Owner and Backlog Management
Explanation: Effective Product Backlog management means the top items are transparent and ordered well enough to support Sprint Planning and product decisions. The Product Owner should collaborate with Developers and use new evidence to refine and reorder the top of the backlog, while remaining accountable for the result.
The key issue is whether Product Backlog management is effective enough right now. In this scenario, it is not: the top items are too vague for Sprint Planning, and recent customer feedback has not been made transparent enough for stakeholder conversations or empirical ordering decisions.
The best action is to improve the top of the Product Backlog now by collaborating with Developers to create enough clarity and by reordering based on the latest evidence and the Product Goal. The Product Owner may delegate preparation work, such as drafting or analysis, but remains accountable for effective Product Backlog management. Scrum does not require the whole Product Backlog to be fully detailed; it needs enough transparency, especially near the top, to enable useful planning and adaptation.
The main takeaway is that effective Product Backlog management creates just enough clarity for the next decision, not exhaustive upfront specification or stakeholder-controlled ordering.
This restores enough transparency at the top of the Product Backlog for Sprint Planning, stakeholder discussion, and empirical value decisions while preserving Product Owner accountability.
Topic: Managing Products with Agility
A product’s business objective is to increase trial-to-paid conversion for self-service customers. At the Sprint Review, data showed that 38% of trial users abandon setup at step 2. Sales then asked for a custom export feature for two large prospects.
The top of the Product Backlog now looks like this:
What is the best Product Owner response?
Best answer: B
What this tests: Managing Products with Agility
Explanation: The Product Owner should order the Product Backlog to maximize value toward the business objective. Here, the strongest evidence points to setup abandonment as the bigger lever for conversion, so the setup item should move up even if it needs more refinement.
A Product Owner connects backlog decisions to business outcomes, not just stakeholder pressure or item readiness. The business objective is improving trial-to-paid conversion, and the Sprint Review produced evidence that many users drop off during setup. That makes simplifying setup the strongest value-oriented next focus.
Being well refined does not automatically make an item the highest priority. Refinement supports transparency and Sprint Planning readiness, but ordering should reflect value, learning, risk, and progress toward the Product Goal or business objective. Sales input matters, yet the Product Owner remains accountable for ordering the Product Backlog.
The closest trap is choosing the already refined export item, but readiness is not the same as priority.
It best aligns the Product Backlog with the stated business objective and uses evidence from the Sprint Review, while refinement can continue collaboratively.
Topic: Understanding and Applying the Scrum Framework
A Product Owner notices the Sprint Review has become a slide-based meeting for senior managers: planned versus completed work, budget burn, and red/amber/green status. Customers rarely attend, and discussion about market changes is deferred to a monthly steering committee. The Scrum Team wants one change for the next Sprint Review. Which option best fits the purpose of the event?
Best answer: C
What this tests: Understanding and Applying the Scrum Framework
Explanation: The Sprint Review is not a status meeting or approval gate. Its purpose is to inspect the Increment with stakeholders and adapt what to do next, using feedback and current conditions to improve product value.
The key concept is the purpose of the Sprint Review: inspect the outcome of the Sprint and determine future adaptations. In this scenario, the current format emphasizes reporting output to managers, while customer feedback and market learning are delayed elsewhere. That weakens empiricism and slows value decisions.
Using the Done Increment with stakeholders in the Sprint Review creates transparency about what was actually achieved, invites feedback from the people affected by the product, and helps the Product Owner adapt the Product Backlog based on evidence. That best supports learning, value, and progress toward the Product Goal under uncertainty.
A dashboard or formal sign-off may be optional organizational practices, but they do not define the event’s Scrum purpose.
The Sprint Review exists to inspect the outcome of the Sprint with stakeholders and determine future adaptations based on current evidence.
Topic: Managing Products with Agility
At a Sprint Review for an expense product, the Scrum Team demonstrates a Done Increment that automates policy suggestions. Customers say their need has shifted: the main delay is now managers approving reports on phones, and usage data shows the new suggestions are rarely used. The Product Goal is to reduce approval cycle time by 40%. A sales director asks the Product Owner to keep the current Product Backlog order for a promised prospect demo. What should the Product Owner do?
Best answer: C
What this tests: Managing Products with Agility
Explanation: Sprint Review feedback should drive adaptation when it reveals a changed customer need or Product Goal risk. The Product Owner should use that evidence to re-order the Product Backlog toward the most valuable next step and make the impact on the Product Goal visible.
The Sprint Review is where the Scrum Team and stakeholders inspect the outcome of the Sprint and determine future adaptations. When feedback and usage evidence show that a customer need has changed, the Product Owner should adapt Product Backlog ordering to maximize value and reduce Product Goal risk.
Here, mobile approvals now appear more relevant to reducing approval cycle time than the low-adoption suggestion feature. The best response is to re-order upcoming work toward that need, communicate the risk to the current Product Goal transparently, and continue learning empirically from future Done Increments. Preserving the old order for forecast stability or a single stakeholder promise delays adaptation, while asking Developers to choose product priority shifts Product Owner accountability.
This uses Sprint Review evidence to adapt the Product Backlog toward higher value while preserving Product Owner accountability and transparency.
When repeated unseen attempts are comfortably above the target range, schedule the real assessment instead of overtraining on the bank. The useful skill is deciding from evidence and Scrum accountability, not recognizing repeated answer text.
This page gives one complete PSPO I diagnostic. PM Mastery adds the larger Product Owner bank, focused topic drills, mixed timed mocks, progress tracking, and explanations for close value, stakeholder, and Product Backlog choices.
Do not immediately rerun the same public set. Review misses, summarize the Product Owner principle behind each one, then drill the weakest topic before attempting another timed run.
Use the PSPO I Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Use the full PM Mastery practice page above for the latest review links and practice route.