Try 10 focused PSM II questions on Product, Stakeholder, and Technical-Risk Support, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | PSM II |
| Topic area | Product, Stakeholder, and Technical-Risk Support |
| Blueprint weight | 18% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Product, Stakeholder, and Technical-Risk Support for PSM II. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 18% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Product, Stakeholder, and Technical-Risk Support
A Scrum Team is one Sprint away from a major customer demo. Several Product Backlog items are marked “done” in the tool, but they are not integrated and do not meet the Definition of Done. Developers have stopped raising a recurring test-environment problem because leaders react badly to delays, and the Product Owner wants the Sprint Review replaced with a status deck. Which action should the Scrum Master take next?
Best answer: C
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: The next best step is to restore transparency around the actual Increment and the real impediments. A Scrum Master should facilitate inspection using the Definition of Done and the upcoming Sprint Review, not hide the problem longer, become a quality gatekeeper, or replace empiricism with reporting.
Under delivery pressure, the Scrum Master’s next move is to re-establish transparency, because inspection and adaptation only work when the real state of the product is visible. In this scenario, work is being labeled done before it meets the Definition of Done, a recurring impediment is being suppressed, and the Sprint Review is being turned into status theater. The Scrum Master should facilitate a fact-based conversation with the Product Owner and Developers around the actual Increment, the Definition of Done, and the impediment’s impact, then help them use the Sprint Review for genuine inspection and adaptation.
Escalation may still be needed later, but not instead of first restoring transparency.
This restores transparency and empiricism while preserving the Product Owner’s and Developers’ accountabilities.
Topic: Product, Stakeholder, and Technical-Risk Support
A Scrum Team’s Definition of Done requires code to be integrated, automated regression tests to pass, and security checks to be completed. At the Sprint Review, stakeholders like a new feature after seeing it deployed to a test environment and ask the Product Owner to count it as done for the release. One required security check is still open, and Developers suggest finishing it in a hardening Sprint next month.
Select ONE: Which accountability boundary best fits this situation?
Best answer: D
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: In Scrum, Done is determined by the Definition of Done, not by stakeholder approval, a successful demonstration, or deployment to a test environment. Because a required security check is still incomplete, the feature is not Done and cannot be treated as part of the Increment.
The key boundary is between value feedback and product quality. Stakeholders can like the feature, the Product Owner can see value in it, and the team can demonstrate it in Sprint Review, but none of those conditions override the Definition of Done. In Scrum, only work that meets the Definition of Done becomes part of the Increment.
A plan to harden later is still a plan for unfinished work, not evidence of Done.
Only work meeting the Definition of Done is part of the Increment, and Developers are accountable for adhering to that quality commitment.
Topic: Product, Stakeholder, and Technical-Risk Support
A Scrum Master notices that for the last three Sprints, several Product Backlog items shown in the Sprint Review later fail integration testing performed by an external test group. Stakeholders are using Sprint Review outcomes to plan a launch in one month, and the Product Owner is under pressure to count “feature-complete” items as Done before that testing finishes. What is the best action for the Scrum Master? Select ONE.
Best answer: C
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: Repeated post-review failures show that the Sprint Review is being informed by incomplete quality evidence. The Scrum Master should restore transparency by helping the Scrum Team inspect the Definition of Done and base forecasts only on work that truly meets it.
The Definition of Done is the commitment for the Increment. If integration testing is still outstanding, the work is not Done and should not be treated as part of the Increment for release decisions. In this situation, the Scrum Master’s best intervention is to increase transparency and facilitate inspection: help the Product Owner, Developers, and any affected groups examine the current DoD gap, show its impact on launch forecasting, and adapt plans so Sprint Reviews are based on work that actually meets the DoD. That preserves empiricism and exposes technical risk early. Adding gates, deferring testing, or redefining incomplete work as Done may make the review look smoother, but they hide risk and usually increase rework later.
This restores transparency and keeps Sprint Reviews and launch decisions grounded in actual Done Increments.
Topic: Product, Stakeholder, and Technical-Risk Support
A Scrum Master sees a pattern over four Sprints: Sprint Planning becomes the first detailed discussion of selected Product Backlog items, and stakeholders say Sprint Review feedback “disappears” because they cannot see it reflected in the Product Backlog. The Product Owner says they are reacting to competing requests and cannot get stakeholders and Developers to inspect trade-offs before Planning. What is the best response from the Scrum Master?
Best answer: B
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: The problem is broader than a private Product Owner skill gap. Facilitating a joint inspection makes weak Product Backlog management transparent to the people affected and supports empirical improvement without the Scrum Master assuming product accountability.
When Sprint Planning becomes the first place selected work is really understood, and Sprint Review feedback is not visible in the Product Backlog, Product Backlog management is weak. That reduces Planning effectiveness, erodes stakeholder trust, and weakens empirical adaptation.
The Scrum Master should choose a stance that helps the Product Owner, Developers, and stakeholders inspect the problem together. Facilitation is best here because the issue spans multiple parties: refinement is happening too late, ordering trade-offs are unclear, and feedback is not transparently reflected. A facilitated conversation can expose those patterns and help the group improve how they refine, surface feedback, and collaborate before Sprint Planning while preserving the Product Owner’s accountability for the Product Backlog.
The key is to increase transparency and enable better behavior, not to rescue the Product Owner or move discovery work into Sprint Planning.
This makes weak Product Backlog management visible to the right people and helps them improve it without taking over the Product Owner’s accountability.
Topic: Product, Stakeholder, and Technical-Risk Support
During Sprint Review, a sales director insists each demonstrated feature must be marked “approved” before it counts as completed work and asks the Scrum Master to run the event as a sign-off session. The Increment already meets the Definition of Done, and the Product Owner wants stakeholder input to adjust future priorities. Which boundary should the Scrum Master clarify? Select ONE.
Best answer: D
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: A Sprint Review is a working session for the Scrum Team and stakeholders to inspect the Increment and discuss what to do next. It is not an approval gate, and work that meets the Definition of Done is already part of the Increment.
The key boundary is between stakeholder input and Scrum accountabilities. In the Sprint Review, stakeholders help inspect the outcome of the Sprint and share feedback, risks, and market information. That input can lead to Product Backlog changes, but the Product Owner remains accountable for Product Backlog management. Separately, whether work is part of the Increment is determined by meeting the Definition of Done, not by stakeholder approval during the event.
Turning the Sprint Review into a sign-off or status session weakens empiricism: it shifts focus from collaborative inspection and adaptation to gatekeeping or reporting. Stakeholder feedback is essential, but it should inform future decisions, not redefine whether already-Done work is complete.
This preserves Sprint Review as an inspect-and-adapt session while keeping Product Backlog decisions with the Product Owner and completion tied to the Definition of Done.
Topic: Product, Stakeholder, and Technical-Risk Support
A Scrum Master sees a pattern over four Sprints: Sprint Planning starts with Developers trying to understand the top Product Backlog items, stakeholders say they cannot see why requests move up or down, and feedback from Sprint Reviews rarely affects the next Sprint’s selections. The Product Owner says, “We can sort it out during Planning.” What is the best response from the Scrum Master?
Best answer: C
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: The symptoms point to weak Product Backlog management: unclear top items, opaque ordering, and little adaptation from Sprint Review feedback. The best Scrum Master response is to increase transparency and facilitate better refinement and collaboration while preserving the Product Owner’s accountability for the Product Backlog.
In Scrum, Sprint Planning is more effective when the Product Backlog is transparent enough that the Product Owner and Developers can discuss value, selection, and a Sprint Goal instead of discovering basic intent too late. Here, repeated clarification of top items, stakeholder confusion about ordering, and ignored Sprint Review feedback all show weak Product Backlog management. The Scrum Master should help the Product Owner improve how the backlog is ordered and refined, and help Developers and stakeholders participate in that transparency without taking product decisions away from the Product Owner.
A forced ranking exercise or an administrative checklist treats the symptom, not the empirical problem.
This makes weak Product Backlog management visible and improves refinement and adaptation without taking over the Product Owner’s accountability.
Topic: Product, Stakeholder, and Technical-Risk Support
Two days before the Sprint ends, Developers stop mentioning an unstable test environment because leadership is pushing for a release date. The Product Owner also wants partially integrated items that do not meet the Definition of Done shown as complete in the Sprint Review. What is the best Scrum Master action?
Best answer: A
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: When delivery pressure causes people to hide reality, the Scrum Master’s best response is to restore transparency immediately. Making undone work and impediments visible allows the Scrum Team and Product Owner to inspect the actual situation and adapt responsibly.
This situation is primarily a transparency and empiricism problem, not just a knowledge gap. Work that does not meet the Definition of Done is not part of a Done Increment, and an ignored impediment reduces the Scrum Team’s ability to inspect and adapt. The Scrum Master should help make both issues visible right away and facilitate the necessary conversation.
That preserves professional delivery and sustainable pace. Teaching only, rescuing the team, or waiting until later all leave the hidden risk in place too long.
This restores empiricism by exposing reality immediately and enabling inspection and adaptation before more false progress accumulates.
Topic: Product, Stakeholder, and Technical-Risk Support
During the last four Sprints, Developers say in the Daily Scrum that work is “on track” and most items are “90% complete.” At Sprint Review, several selected Product Backlog items still lack performance testing and system integration because another group provides the environment later during “release prep.” Defects are discovered late, but management asks only for better progress reporting. What should the Scrum Master do?
Best answer: B
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: The core problem is false transparency: progress is being reported while key quality work is deferred. The Scrum Master should make that gap visible against the Definition of Done and help address the dependency that keeps technical risk hidden.
This situation shows reporting activity instead of inspecting a real Increment. If performance testing and integration happen later, the work is not Done yet, so “90% complete” hides technical risk rather than creating transparency. The Scrum Master should help the Developers and Product Owner compare current practice to the Definition of Done, make deferred work visible, and ensure only Done work is treated as part of the Increment. Because another group controls the needed environment, the Scrum Master should also help expose that as an organizational impediment and work toward removing or reducing it. Better status reporting, a hardening Sprint, or early acceptance all preserve the same hidden-risk pattern instead of fixing it.
This exposes hidden technical risk, ensures only Done work counts in the Increment, and helps remove the organizational constraint causing deferral.
Topic: Product, Stakeholder, and Technical-Risk Support
A Scrum Team has a recurring problem. In Sprint Planning, Developers interpret Product Backlog items differently. In Sprint Review, stakeholders say the backlog still does not make clear what outcomes are being pursued next or why items are ordered as they are. The Product Owner asks the Scrum Master to “translate the backlog for everyone” before each event. What is the best response? Select ONE.
Best answer: D
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: The recurring issue is insufficient Product Backlog transparency, not a missing translator. The Scrum Master should help the Product Owner and Developers create shared understanding of value, ordering, and the Product Goal so stakeholders can inspect and adapt effectively.
When Developers and stakeholders cannot understand the Product Backlog well enough, the underlying problem is weak transparency. In Scrum, the Scrum Master helps the Product Owner find effective Product Backlog management techniques without taking over product accountability. Here, the best response is to coach the Product Owner and facilitate collaborative refinement so backlog items are understandable enough for Developers to plan and for stakeholders to give useful feedback about future adaptation.
This improves three things:
Writing summaries on the Product Owner’s behalf may reduce confusion briefly, but it creates dependency instead of fixing the source problem.
This addresses the real constraint—poor Product Backlog transparency—while preserving the Product Owner’s accountability.
Topic: Product, Stakeholder, and Technical-Risk Support
Midway through a Sprint, Developers tell the Scrum Master that several Product Backlog items are “90% complete.” They plan to defer integration testing and a known performance defect until a later Sprint so the Sprint Review will show more features. The Definition of Done requires integrated, tested, releasable work, and the Product Owner is forecasting delivery to stakeholders from these progress percentages. What is the best action for the Scrum Master? Select ONE.
Best answer: A
What this tests: Product, Stakeholder, and Technical-Risk Support
Explanation: The Scrum Master’s best move is to increase transparency immediately. If testing and defect work required by the Definition of Done are deferred, the reported progress hides technical risk, so the Scrum Team and Product Owner need to inspect that reality and adapt now.
In Scrum, meaningful progress is tied to a Done Increment, not to items that appear almost finished. Here, integration testing and a known defect are being postponed even though the Definition of Done requires integrated, tested, releasable work. That means the percentage-complete reports create false confidence and hide technical risk.
The Scrum Master should serve by making that risk transparent, teaching the distinction between progress reporting and Done work, and facilitating a conversation between Developers and the Product Owner so they can adapt the Sprint Backlog and stakeholder expectations based on what can truly meet the Definition of Done. The Scrum Master should not normalize deferred quality work, postpone the discussion, or create extra reporting that keeps the real quality picture outside normal Scrum inspection. The closest distractor delays action until the Retrospective, but the problem is already distorting current decisions.
This makes technical risk transparent now and restores inspection and adaptation around Done work instead of percentage-complete reporting.
Use the PSM II 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.