PSM II — Scrum.org Professional Scrum Master II Scenario Practice Guide

The Scrum.org Professional Scrum Master II (PSM II) exam expects more than memorizing Scrum terms. Many questions are scenario-based: a team is struggling, a stakeholder is unhappy, management is applying pressure, a Product Owner is unavailable, or a Scrum event is not producing useful inspection and adaptation.

This guide gives you a practical way to slow down, read the scenario, and choose the most defensible answer from the facts provided. It is an independent exam-preparation resource and is not affiliated with Scrum.org.

The core mindset for PSM II scenarios

In a PSM II scenario, the “best” answer is usually the one that best supports Scrum, empiricism, accountability, self-management, and continuous improvement.

Before looking for an action, ask:

• What is actually happening?
• Who is accountable for the decision?
• Is the issue about transparency, inspection, adaptation, quality, value, collaboration, or organizational impediments?
• Should the Scrum Master teach, coach, facilitate, or help remove an impediment?
• Is immediate action needed, or should the Scrum Master first create transparency and enable the right people to decide?

The Scrum Master is not a project manager who assigns tasks, controls scope, approves technical decisions, or acts as a buffer that hides problems. In scenarios, the Scrum Master’s best move often improves the system so the Scrum Team can make better decisions.

Step 1: Identify the Scrum Master’s role in the scenario

Start by locating the perspective. PSM II questions often ask what the Scrum Master should do, but the facts may involve the Product Owner, Developers, stakeholders, management, or multiple Scrum Teams.

If the scenario is about Developers

Look for whether the issue concerns:

• Creating a usable Increment each Sprint
• Meeting the Definition of Done
• Managing the Sprint Backlog
• Planning and adapting work during the Sprint
• Technical quality, dependencies, or collaboration
• Self-management and ownership of the work

The Scrum Master should generally not assign tasks, decide who works on what, or solve technical problems for the Developers. A stronger answer usually helps the Developers inspect, adapt, collaborate, and own the outcome.

Good Scrum Master reasoning:

• “How can I help the Developers make this transparent?”
• “Do they understand their accountability for quality and the Increment?”
• “Would facilitation help them inspect the problem and adapt their plan?”
• “Is there an impediment they cannot remove alone?”

If the scenario is about the Product Owner

Look for whether the issue concerns:

• Product Goal
• Product Backlog ordering
• Product Backlog transparency
• Maximizing value
• Stakeholder engagement
• Clear communication of product direction

The Scrum Master does not take over Product Owner accountability. The Scrum Master may coach the Product Owner, help improve stakeholder collaboration, or teach how Scrum supports value delivery.

Good Scrum Master reasoning:

• “Is the Product Owner able to make ordering decisions based on value?”
• “Are stakeholders bypassing the Product Owner or forcing commitments?”
• “Does the Product Backlog make product direction transparent?”
• “Would coaching the Product Owner or stakeholders be the best next step?”

If the scenario is about stakeholders or management

Look for whether the issue concerns:

• Misunderstanding Scrum accountabilities
• Pressure to commit to fixed scope
• Interruptions during the Sprint
• Requests to skip quality practices
• Demands for status reporting that replace empirical inspection
• Organizational impediments that affect the Scrum Team

The Scrum Master should not simply comply with pressure, but also should not become combative. The strongest answer usually teaches, facilitates transparency, and helps the organization understand how Scrum works.

Good Scrum Master reasoning:

• “What does management need to understand about Scrum?”
• “How can stakeholders inspect progress through the right event or artifact?”
• “Is the pressure causing reduced transparency or lower quality?”
• “Can the Scrum Master facilitate a conversation rather than make the decision?”

Step 2: Determine whether the problem is about Scrum mechanics or Scrum purpose

Some scenarios are about whether a rule is being followed. Others are about whether the team is gaining the benefits of Scrum.

For PSM II, do not stop at the surface behavior. Ask what Scrum purpose is being weakened.

Examples:

• A Daily Scrum is happening, but the Developers are reporting to the Scrum Master. The deeper issue is not the meeting format. The deeper issue is loss of ownership and self-management.

• A Sprint Review is held, but stakeholders do not attend or provide feedback. The deeper issue is weak inspection of the Increment and poor adaptation of product direction.

• A Retrospective produces action items, but nothing changes. The deeper issue is lack of meaningful adaptation and continuous improvement.

• A Product Backlog exists, but nobody understands what is most valuable. The deeper issue is weak transparency and impaired value-based decision-making.

In a scenario, the best answer often addresses the purpose behind the Scrum element, not just the visible symptom.

Step 3: Find the actual decision point

Scenario questions often include several facts. Some facts are context; one fact usually creates the decision point.

Read the final sentence carefully. It may ask:

• What should the Scrum Master do first?
• What is the best next step?
• What should the Scrum Master advise?
• What is the most appropriate response?
• Which actions would help the team?
• What is the likely impact?

The wording matters.

“First” means sequence matters

If the question asks what to do first, avoid jumping to a final solution. The best first step may be to make the issue transparent, facilitate a conversation, or understand the cause before acting.

Example reasoning:

• If stakeholders are unhappy with what was delivered, first inspect why expectations and product direction diverged.
• If Developers are missing the Sprint Goal, first help them inspect their Sprint Backlog and adapt their plan.
• If management demands a change during the Sprint, first clarify how the change relates to the Sprint Goal and Product Backlog ordering.

“Best” means most aligned with Scrum

If the question asks for the best action, compare options against Scrum accountabilities and empiricism.

A strong answer usually:

• Respects the accountability of the Product Owner, Developers, and Scrum Master
• Improves transparency
• Enables inspection and adaptation
• Supports self-management
• Protects quality and the Definition of Done
• Helps the organization learn rather than forcing compliance

“Advise” means teach without taking over

If the Scrum Master is advising, the answer should usually help the accountable person make a better decision. Advising is not the same as deciding for them.

For example:

• Coach the Product Owner on ordering and stakeholder engagement.
• Help Developers understand their responsibility for quality and the Increment.
• Teach managers how changes can be handled through Product Backlog ordering and Sprint boundaries.

Step 4: Separate facts from distractors

A PSM II scenario may include emotional or urgent details: a senior stakeholder is upset, a release is approaching, leadership wants certainty, or the team is behind. These details matter, but they do not automatically override Scrum principles.

As you read, mark facts in three categories.

Facts that define accountability

These tell you who should decide.

Look for:

• Who owns the Product Backlog?
• Who manages the Sprint Backlog?
• Who is accountable for the Increment meeting the Definition of Done?
• Who facilitates or coaches?
• Who is asking for the change?

Facts that define the empirical problem

These tell you what is not transparent, inspected, or adapted.

Look for:

• Hidden work
• Unclear Product Backlog items
• Unknown progress toward the Sprint Goal
• Missing stakeholder feedback
• Poor Sprint Review outcomes
• Retrospective actions not implemented
• Quality problems discovered late

Facts that define organizational constraints

These tell you whether the Scrum Master may need to help remove impediments beyond the team.

Look for:

• External approval gates
• Functional silos
• Competing priorities assigned by managers
• Policies that prevent collaboration
• Stakeholders bypassing accountabilities
• Multiple teams lacking alignment on one product

Do not let dramatic facts distract you from the decision point. Urgency may increase the need for transparency and collaboration, but it does not justify abandoning Scrum accountability.

Step 5: Use empiricism as the decision filter

Scrum is founded on empiricism. In scenario questions, empiricism gives you a reliable reasoning filter.

Ask:

• What information is visible?
• What needs to be inspected?
• What adaptation is needed?
• Who should participate in that inspection and adaptation?
• Which Scrum event or artifact supports that?

Transparency

If people are making decisions with incomplete or hidden information, the Scrum Master should often help make the situation visible.

Examples:

• Make progress toward the Sprint Goal transparent.
• Make quality problems visible through the Definition of Done.
• Make Product Backlog ordering clear.
• Make stakeholder feedback visible during Sprint Review.
• Make organizational impediments visible to those who can help remove them.

Inspection

If the issue is uncertainty, poor feedback, or disagreement, the answer may involve inspecting the Increment, Product Backlog, Sprint Goal, or team process.

Examples:

• Use Sprint Review for inspecting the Increment and adapting the Product Backlog.
• Use Sprint Retrospective for inspecting how the Scrum Team works together.
• Use Daily Scrum for Developers to inspect progress toward the Sprint Goal.
• Use refinement as an ongoing activity to improve shared understanding of Product Backlog items.

Adaptation

If inspection reveals a problem, the answer should enable adaptation by the right people.

Examples:

• Developers adapt the Sprint Backlog.
• Product Owner adapts Product Backlog ordering.
• Scrum Team adapts its working agreements or process.
• Organization adapts policies that create impediments.

A choice that creates transparency, enables inspection, and supports adaptation is often more defensible than a choice that simply commands compliance.

Step 6: Decide whether communication, analysis, action, or escalation comes first

Many project-management-style scenarios test sequencing. PSM II scenarios do this through the Scrum Master’s stance.

When communication comes first

Choose communication first when the problem involves misunderstanding, misalignment, hidden expectations, or unclear accountability.

Examples:

• Stakeholders do not understand why the team cannot accept every mid-Sprint request.
• Management expects the Scrum Master to assign work.
• Developers believe the Product Owner alone is responsible for Sprint outcomes.
• The Product Owner is not collaborating with stakeholders.

The Scrum Master may facilitate a conversation, coach participants, or teach Scrum accountabilities.

When analysis comes first

Choose analysis first when the facts do not yet reveal the root cause.

Examples:

• Velocity or throughput has changed, but the reason is unclear.
• A team repeatedly misses Sprint Goals, but the scenario does not say why.
• Stakeholders are dissatisfied, but the scenario does not explain whether the issue is value, quality, timing, or expectations.

In Scrum terms, analysis often means creating transparency and helping the team inspect the situation. It does not mean producing a heavyweight report before learning.

When action comes first

Choose action first when Scrum accountability is clear and the next step supports it.

Examples:

• The Developers discover they cannot meet the Sprint Goal. They should inspect and adapt the Sprint Backlog.
• The Product Owner learns a major market change affects value. The Product Owner should consider adapting Product Backlog ordering.
• The Scrum Team identifies an improvement in the Retrospective. They should plan a concrete adaptation.

The Scrum Master’s action is often to facilitate, coach, or remove impediments rather than personally direct the solution.

When escalation is appropriate

Escalation is not usually the first reflex. Consider it only when the issue is outside the Scrum Team’s ability to resolve or when organizational impediments must be addressed by people with authority over the system.

Before escalating, ask:

• Has the issue been made transparent?
• Have the right accountabilities been respected?
• Has the Scrum Team had a chance to inspect and adapt?
• Is the impediment truly outside the team’s control?
• Would escalation help remove the impediment, or would it bypass self-management?

A defensible escalation supports the team and the product. It does not replace the team’s ownership.

Step 7: Read delivery context without forcing a project-management template

PSM II is Scrum-focused. Do not force predictive project-management logic onto Scrum scenarios.

Instead of asking, “Who approves the plan?” ask:

• What is the Sprint Goal?
• What is the current Increment?
• What does the Product Backlog make transparent?
• Who is accountable for value?
• Who manages the Sprint Backlog?
• What inspection and adaptation opportunity is available?
• What is the Scrum Master helping the team or organization learn?

Scrum does not remove planning, forecasting, risk management, or stakeholder management. It handles them empirically. In scenario practice, prefer answers that support frequent inspection and adaptation over answers that create rigid control mechanisms.

Scenario patterns and how to reason through them

Use the following patterns as reading practice. The point is not to memorize responses, but to train your decision sequence.

Stakeholder demands a change during the Sprint

Read for:

• Does the change threaten the Sprint Goal?
• Is the Product Owner involved?
• Are stakeholders bypassing the Product Owner?
• Are Developers being interrupted?
• Is the change truly urgent, or is it a Product Backlog ordering issue?

Reasoning path:

1. Protect transparency around the Sprint Goal and current work.
2. Respect the Product Owner’s accountability for Product Backlog ordering.
3. Respect the Developers’ accountability for managing the Sprint Backlog.
4. Facilitate conversation if trade-offs are needed.
5. Avoid having the Scrum Master approve or reject the change unilaterally.

A strong answer usually keeps the Product Owner and Developers in the decision loop.

Developers are not completing work to the Definition of Done

Read for:

• Is the Definition of Done clear and understood?
• Are quality problems being hidden?
• Is pressure causing undone work?
• Are Developers treating testing, integration, or documentation as separate later phases?
• Is the Increment usable?

Reasoning path:

1. Make the quality gap transparent.
2. Reinforce that the Increment must meet the Definition of Done.
3. Help the Developers inspect why they are not meeting it.
4. Facilitate improvement through Sprint Retrospective or immediate collaboration if needed.
5. Coach stakeholders and management if pressure is encouraging lower quality.

A strong answer protects quality without the Scrum Master becoming the technical manager.

Product Owner is unavailable or disengaged

Read for:

• Is Product Backlog ordering suffering?
• Are Developers lacking product direction?
• Are stakeholders unable to provide input?
• Is the Product Goal unclear?
• Is the Scrum Master being asked to fill the Product Owner role?

Reasoning path:

1. Identify the impact on transparency, value, and decision-making.
2. Coach the Product Owner on the effects of unavailability.
3. Help improve collaboration between the Product Owner, Developers, and stakeholders.
4. If the organization’s structure prevents effective product ownership, make that impediment visible.
5. Do not have the Scrum Master take over Product Backlog accountability.

A strong answer supports effective product ownership rather than masking the problem.

Daily Scrum becomes a status meeting

Read for:

• Are Developers speaking to the Scrum Master instead of each other?
• Is the meeting helping inspect progress toward the Sprint Goal?
• Are impediments being raised but not addressed?
• Are people using the event to report rather than plan?

Reasoning path:

1. Remember that the Daily Scrum is for the Developers.
2. Focus on inspection of progress toward the Sprint Goal.
3. Coach the Developers to adapt the Sprint Backlog as needed.
4. Avoid turning the Scrum Master into the meeting controller.

A strong answer improves the event’s purpose and team ownership.

Sprint Review is treated as a sign-off meeting

Read for:

• Are stakeholders inspecting the Increment?
• Is feedback being used to adapt the Product Backlog?
• Is the conversation limited to approval or rejection?
• Is the Increment actually usable?
• Is the Product Owner using the event to improve product direction?

Reasoning path:

1. Recenter the event on inspection and adaptation.
2. Encourage meaningful stakeholder participation.
3. Help the Scrum Team and stakeholders discuss what was learned.
4. Ensure feedback can influence the Product Backlog.
5. Avoid treating the Sprint Review as a formal acceptance gate.

A strong answer strengthens empirical product management.

Retrospective produces no improvement

Read for:

• Are team members being honest?
• Are improvements too vague?
• Are impediments outside the team being ignored?
• Are previous actions forgotten?
• Is psychological safety weak?

Reasoning path:

1. Help create transparency about why improvement is not happening.
2. Facilitate a focused inspection of the team’s process and relationships.
3. Encourage a small, concrete adaptation.
4. Help remove impediments where appropriate.
5. Follow through so adaptation becomes real.

A strong answer makes continuous improvement practical, not ceremonial.

Multiple Scrum Teams work on one product

Read for:

• Is there one product or several products?
• Is there one Product Backlog for the product?
• Is there one Product Owner accountable for value?
• Are teams integrating work into a usable Increment?
• Are dependencies reducing transparency or slowing adaptation?

Reasoning path:

1. Clarify the product boundary and product accountability.
2. Look for transparency around integrated progress.
3. Support collaboration among teams without removing self-management.
4. Focus on producing a usable integrated Increment each Sprint.
5. Avoid adding coordination layers that obscure accountability.

A strong answer improves integration and transparency while preserving Scrum accountabilities.

How to compare answer choices

When two answers sound reasonable, compare them through these filters.

Accountability filter

Ask: “Does this answer give the decision to the right accountability?”

• Product Owner: value, Product Goal, Product Backlog ordering
• Developers: Sprint Backlog, technical execution, quality of the Increment
• Scrum Master: Scrum effectiveness, coaching, facilitation, impediment removal
• Scrum Team: shared focus on the Product Goal, Sprint Goal, Increment, and continuous improvement

Reject answers that quietly transfer accountability to the wrong person.

Empiricism filter

Ask: “Does this answer improve transparency, inspection, and adaptation?”

A choice that hides information, delays feedback, or prevents adaptation is weak even if it sounds efficient.

Self-management filter

Ask: “Does this answer help the team become more capable, or does it create dependency?”

The Scrum Master should not become the person who approves all decisions, assigns all work, or resolves all conflict by authority.

Value filter

Ask: “Does this answer help maximize value?”

For Product Owner and stakeholder scenarios, value matters. The best answer often helps clarify goals, order the Product Backlog, improve feedback, or align stakeholders around product outcomes.

Quality filter

Ask: “Does this answer preserve the Definition of Done and the usability of the Increment?”

Pressure, deadlines, and stakeholder urgency do not make undone work acceptable. Strong answers make quality transparent and help the team improve how it delivers.

A compact reading checklist for PSM II scenarios

Use this checklist during practice until it becomes automatic.

1. Who is the Scrum Master serving? Developers, Product Owner, Scrum Team, stakeholders, or organization?

2. What Scrum accountability is involved? Product Backlog, Sprint Backlog, Increment, Definition of Done, Sprint Goal, or Scrum effectiveness?

3. What is the real problem? Low transparency, poor inspection, weak adaptation, unclear value, quality issue, team conflict, or organizational impediment?

4. What does the question ask for? First step, best action, advice, likely impact, or multiple helpful actions?

5. Who should decide? Do not let the Scrum Master take over another accountability.

6. What should happen before escalation? Make the issue transparent, inspect with the right people, and enable adaptation.

7. Which answer improves Scrum over time? Prefer coaching, facilitation, learning, transparency, and ownership over command-and-control fixes.

Mini practice examples

Example 1: Product Owner under pressure

A senior stakeholder tells the Developers to add a new feature during the Sprint. The Developers are unsure whether to accept it. The Sprint Goal may be affected.

A strong reasoning sequence:

• The stakeholder should not bypass Product Owner accountability.
• The Developers manage the Sprint Backlog and must understand impact on the Sprint Goal.
• The Product Owner is accountable for ordering Product Backlog items and value decisions.
• The Scrum Master can facilitate a conversation and teach the accountabilities involved.

The most defensible answer would not be for the Scrum Master to approve the change. It would involve transparency, the Product Owner, the Developers, and the Sprint Goal.

Example 2: Team repeatedly misses Sprint Goals

A Scrum Team often starts more work than it finishes. Stakeholders are losing confidence.

A strong reasoning sequence:

• The issue may involve Sprint Planning, forecasting, Product Backlog refinement, focus, or interruptions.
• The Scrum Master should not simply demand more detailed commitments.
• The team needs to inspect why the pattern occurs.
• The Sprint Retrospective may be useful, but if the problem is visible now, transparency and adaptation should not wait unnecessarily.
• The Scrum Master can facilitate inspection and help remove impediments.

The most defensible answer helps the team learn and adapt rather than imposing a productivity target.

Example 3: Management asks for individual performance reports

Management asks the Scrum Master to report which Developers are causing delays.

A strong reasoning sequence:

• The request may damage teamwork and self-management.
• The Scrum Master should help management understand Scrum Team accountability and empirical progress.
• Useful transparency can come from product progress, Sprint Goals, Increments, impediments, and delivery trends.
• The Scrum Master should not hide problems, but should avoid turning Scrum into individual surveillance.

The most defensible answer teaches and redirects transparency toward outcomes and impediments.

Final review habit: explain your answer before selecting it

During final review, do not only check whether you chose the right option. Practice explaining why the answer is defensible.

For each scenario, write one sentence:

• “The real issue is…”
• “The accountable person is…”
• “The Scrum Master should first…”
• “This answer supports Scrum because…”

If you cannot explain the answer using Scrum accountabilities, empiricism, self-management, value, and quality, revisit the scenario before moving on.

Practical next step

Use scenario practice in short, focused sets. After each set, review not just the missed questions, but the decision sequence you used. Then reinforce weak areas with topic drills on Scrum accountabilities, events, artifacts, empiricism, self-management, stakeholder collaboration, and organizational impediments before taking a full mock exam.