PSM II — Scrum.org Professional Scrum Master II Quick Review

Quick Review purpose

This Quick Review is for candidates preparing for the Scrum.org Professional Scrum Master II (PSM II) exam, exam code PSM II. It is designed to help you refresh the most testable ideas before moving into PM Mastery practice, original practice questions, topic drills, mock exams, and detailed explanations.

The PSM II level is less about recalling Scrum vocabulary and more about applying Scrum in difficult situations: unclear accountability, weak transparency, stakeholder pressure, organizational impediments, ineffective events, poor facilitation, misunderstood “commitment,” and Scrum Masters who either do too much or too little.

Use this review to sharpen your decision rules.

What advanced Scrum Master questions usually test

PSM II-style scenarios often ask: What should a Scrum Master do next? The best answer usually protects Scrum’s empirical foundation while helping people improve their own capability.

Core Scrum theory to keep front-of-mind

Scrum is founded on empiricism and lean thinking.

High-yield rule

If a Scrum problem exists, ask:

1. What is not transparent?
2. What inspection is missing or ineffective?
3. What adaptation is being avoided?
4. Which accountability is unclear or being bypassed?
5. What can the Scrum Master do to help people improve without taking over?

Scrum values as decision filters

The Scrum values are not decorative. They guide behavior when the scenario is messy.

Common trap: “commitment” does not mean fixed scope

In Scrum, the Sprint Goal is the commitment for the Sprint Backlog. Developers may adapt the Sprint Backlog during the Sprint as more is learned, while preserving focus on the Sprint Goal.

Accountabilities: know who owns what

Scrum has three accountabilities: Product Owner, Scrum Master, and Developers. Together they form the Scrum Team.

Product Owner review

The Product Owner is accountable for effective Product Backlog management, including:

• Developing and explicitly communicating the Product Goal.
• Creating and clearly communicating Product Backlog items.
• Ordering Product Backlog items.
• Ensuring the Product Backlog is transparent, visible, and understood.

The Product Owner may delegate work, but remains accountable.

Developers review

Developers are accountable for:

• Creating a plan for the Sprint: the Sprint Backlog.
• Instilling quality by adhering to a Definition of Done.
• Adapting their plan each day toward the Sprint Goal.
• Holding each other accountable as professionals.

Developers are self-managing. They decide who does what, when, and how.

Scrum Master review

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team’s effectiveness.

The Scrum Master serves:

The Scrum Master stance: choose the right intervention

A strong PSM II answer often depends on the Scrum Master’s stance.

Decision rule for Scrum Master action

    flowchart TD
	    A[Problem appears] --> B{Is Scrum misunderstood?}
	    B -- Yes --> C[Teach Scrum purpose and accountability]
	    B -- No --> D{Can the Scrum Team solve it?}
	    D -- Yes --> E[Coach or facilitate self-management]
	    D -- No --> F{Is it an organizational impediment?}
	    F -- Yes --> G[Make it transparent and help remove it]
	    F -- No --> H[Create inspection and adaptation]
	    C --> I[Do not take over accountability]
	    E --> I
	    G --> I
	    H --> I

Best answers usually help the system improve. Poor answers often make the Scrum Master a controller, administrator, or hero.

Events: purpose, traps, and exam cues

Scrum events exist to create regularity and enable inspection and adaptation. Do not treat them as ceremonies performed for appearance.

Sprint Planning: high-yield review

Sprint Planning addresses three topics:

1. Why is this Sprint valuable?

   • The Product Owner proposes how the product could increase value.
   • The whole Scrum Team collaborates to define the Sprint Goal.

2. What can be Done this Sprint?

   • Developers select Product Backlog items in discussion with the Product Owner.
   • Past performance, capacity, Definition of Done, and Product Backlog clarity may inform the forecast.

3. How will the chosen work get Done?

   • Developers plan the work necessary to create a Done Increment.

Sprint Planning traps

Daily Scrum: not a status report

The Daily Scrum is for Developers. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.

Good exam answers preserve:

• Developer ownership.
• Focus on the Sprint Goal.
• Adaptation of the plan.
• Transparency about impediments.
• Minimal waste.

Common Daily Scrum mistakes

Sprint Review: product inspection, not acceptance theater

The Sprint Review is a working session where the Scrum Team and stakeholders inspect the outcome of the Sprint and determine future adaptations.

High-yield points:

• It is not limited to a demo.
• It is not a formal gate for approval.
• Stakeholders provide feedback.
• The Product Backlog may be adapted.
• Progress toward the Product Goal is discussed.
• Only Done work is part of the Increment.

Sprint Review trap

If the Sprint Review reveals that stakeholders are surprised, disconnected, or unhappy, the answer is usually not “add more documentation.” Look for better stakeholder collaboration, clearer Product Goal communication, more frequent feedback, improved Product Backlog transparency, or earlier validation.

Sprint Retrospective: improve the system of work

The Sprint Retrospective is the Scrum Team’s opportunity to inspect itself and plan improvements.

Inspect topics such as:

• Individuals and interactions.
• Processes and tools.
• Definition of Done.
• Quality practices.
• Collaboration.
• Communication.
• Impediments.
• Effectiveness.

A useful Retrospective produces concrete adaptations, not just discussion.

Artifacts and commitments

Scrum artifacts maximize transparency. Each artifact has a commitment.

Product Backlog

The Product Backlog is:

• Emergent.
• Ordered.
• Transparent.
• Focused on improving the product.
• The single source of work undertaken by the Scrum Team.

The Product Owner is accountable for Product Backlog management, but may involve others.

Sprint Backlog

The Sprint Backlog contains:

• The Sprint Goal.
• The Product Backlog items selected for the Sprint.
• The plan for delivering the Increment.

It is owned by the Developers and updated throughout the Sprint as more is learned.

Increment

An Increment is a concrete stepping stone toward the Product Goal. It must meet the Definition of Done.

Key points:

• Multiple Increments may be created during a Sprint.
• The Increment must be usable.
• Work that does not meet the Definition of Done is not part of the Increment.
• “Almost done” work creates opacity and risk.

Definition of Done: one of the biggest PSM II topics

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

Decision rules

Common trap: separate testing or hardening Sprint

A separate hardening Sprint usually indicates that each Sprint is not producing a Done, usable Increment. The better answer is to improve engineering practices, Definition of Done, integration, automation, and cross-functionality.

Product Goal and Sprint Goal

Product Goal

The Product Goal describes a future state of the product and provides a target for the Scrum Team to plan against. It is the commitment for the Product Backlog.

Exam cues:

• Helps align decisions.
• Gives meaning to Product Backlog ordering.
• Supports stakeholder communication.
• Reduces output-only thinking.

Sprint Goal

The Sprint Goal is the single objective for the Sprint. It creates coherence and flexibility.

Product Backlog refinement

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items. It is ongoing.

High-yield points:

• Refinement is not a formal Scrum event.
• The Product Owner remains accountable for Product Backlog management.
• Developers are often involved to improve understanding, estimates, and feasibility.
• Refinement should increase transparency and readiness for Sprint Planning.
• Refinement is not a commitment to build the item.

Refinement traps

Forecasting, estimates, and metrics

Scrum does not require a specific estimation technique. Estimates are useful only when they support transparency, planning, and decision-making.

Useful metric thinking

Common metric traps

• Velocity is not value.
• More output is not necessarily better.
• Busyness is not progress.
• Utilization can reduce adaptability.
• A forecast is not a promise.
• Comparing teams by velocity damages transparency.
• Metrics should support learning, not control theater.

Evidence-based product thinking

Advanced Scrum Master scenarios often reward evidence-based thinking: use observable results to guide product and process decisions.

Ask:

• Are stakeholders and users getting value?
• Is the Scrum Team learning quickly?
• Can the organization deliver and adapt frequently?
• Are quality and technical health enabling or limiting innovation?
• Are decisions based on evidence or assumptions?

Output vs outcome

Handling change during a Sprint

A Sprint is not a scope prison. It is a container for focus, learning, and adaptation.

Sprint cancellation

Only the Product Owner has the authority to cancel a Sprint, and this happens if the Sprint Goal becomes obsolete.

Impediments: not all problems are equal

A Scrum Master helps remove impediments, but should not remove every inconvenience in a way that weakens self-management.

Common trap: becoming the team’s assistant

A Scrum Master should not become the person who schedules all meetings, updates all tools, chases every task, collects status, assigns work, or shields the team from all reality. The Scrum Master enables effectiveness, not dependency.

Self-management and cross-functionality

A Scrum Team is self-managing and cross-functional.

Exam traps

Stakeholder collaboration

Stakeholders are essential, but they do not replace Scrum accountabilities.

Product Owner anti-patterns

Developer anti-patterns

Scrum Master anti-patterns

Leadership and organization-level scenarios

PSM II questions often move beyond the Scrum Team. The Scrum Master helps the organization understand what must change for Scrum to work.

Organizational impediments to watch for

• Functional silos.
• Individual performance incentives that discourage teamwork.
• Excessive handoffs.
• Governance that requires phase gates inconsistent with Done Increments.
• Separate testing, security, or release departments that delay integration.
• Managers assigning work directly to Developers.
• Stakeholders bypassing the Product Owner.
• Too many simultaneous initiatives.
• Technical debt hidden by schedule pressure.
• Metrics that reward output instead of value.

Better leadership stance

Scrum-compatible leadership tends to:

• Clarify goals.
• Remove barriers.
• Enable autonomy.
• Support transparency.
• Encourage learning.
• Avoid micromanagement.
• Help teams improve the system.

Scaling and multiple-team situations

When multiple Scrum Teams work on the same product, the same Scrum principles still matter: transparency, integrated quality, shared product focus, and clear accountabilities.

Scaling trap

Do not solve scaling problems by adding layers of managers, coordinators, sign-offs, and status meetings before addressing product structure, dependencies, Definition of Done, and transparency.

Facilitation: what the exam rewards

Facilitation is not controlling the answer. It is helping a group collaborate effectively.

Good facilitation:

• Clarifies purpose.
• Creates participation.
• Makes options visible.
• Helps the group inspect reality.
• Guides toward decisions or experiments.
• Maintains neutrality where appropriate.
• Keeps focus on goals and outcomes.

Poor facilitation:

• Dominates the conversation.
• Forces the Scrum Master’s preferred answer.
• Avoids difficult topics.
• Lets loud voices control the group.
• Produces no adaptation.

Coaching: common scenario pattern

When people are capable of solving a problem but are stuck, coaching is often better than instruction.

Teaching: when direct explanation is appropriate

Teaching is appropriate when Scrum is misunderstood.

Examples:

• Explaining that the Daily Scrum is for Developers.
• Clarifying that the Sprint Review is not a sign-off gate.
• Teaching that work not meeting the Definition of Done is not part of the Increment.
• Explaining Product Owner accountability for Product Backlog management.
• Clarifying that Developers own the Sprint Backlog.

Conflict and difficult conversations

Conflict is not automatically bad. Avoid answers that suppress conflict or let it become personal.

Quality, technical debt, and professionalism

Technical excellence matters because Scrum requires usable Increments.

High-yield points:

• Quality is not optional.
• The Definition of Done creates transparency around quality.
• Technical debt can reduce adaptability.
• Developers are accountable for quality practices.
• The Scrum Master helps make quality problems visible.
• The Product Owner should understand how technical debt affects value and future options.

Technical debt trap

The answer is rarely “ignore technical debt until later.” Better answers expose its impact, include quality improvements in planning, strengthen the Definition of Done, and help stakeholders understand trade-offs.

Release decisions

Scrum separates creating a Done Increment from releasing it. A Done Increment is usable; release timing is a business decision.

“Best answer” filters for PSM II scenarios

When two answers seem plausible, prefer the one that:

1. Preserves Scrum accountabilities.
2. Increases transparency.
3. Enables inspection and adaptation.
4. Supports self-management.
5. Protects the Definition of Done.
6. Focuses on value and goals, not just output.
7. Treats adults as capable professionals.
8. Addresses root causes, not just symptoms.
9. Uses coaching, teaching, or facilitation appropriately.
10. Avoids command-and-control behavior.

Common wrong-answer patterns

Watch for answer choices that sound productive but violate Scrum.

Rapid review table: Scrum event purposes

Rapid review table: artifact transparency

Scenario drills to practice independently

Before taking a mock exam, practice recognizing these scenario types:

1. A stakeholder bypasses the Product Owner.

   • What accountability is being undermined?
   • How can the Scrum Master improve collaboration without becoming a gatekeeper?

2. Developers report to the Scrum Master in the Daily Scrum.

   • What is the event’s purpose?
   • How can the Scrum Master help Developers own inspection and adaptation?

3. The team carries unfinished testing into the next Sprint.

   • What does this reveal about the Definition of Done?
   • What quality and engineering improvements may be needed?

4. Management wants higher velocity.

   • What metric misuse is happening?
   • What evidence would better guide improvement?

5. The Product Owner is unavailable.

   • What transparency and feedback problems result?
   • How can the Scrum Master serve the Product Owner and Scrum Team?

6. A Sprint Review becomes a demo with no adaptation.

   • What inspection is missing?
   • How can stakeholder collaboration improve?

7. Developers wait for task assignments.

   • What self-management problem exists?
   • Should the Scrum Master assign tasks or coach the team?

8. Multiple teams integrate only before release.

   • What does this imply about Done?
   • How can transparency and integration improve?

Final exam-readiness checklist

Use this checklist before moving into topic drills and mock exams.

Practice next

After this Quick Review, move into PM Mastery practice: start with focused topic drills on Scrum Master stances, events, artifacts, Definition of Done, Product Owner accountability, and organizational impediments. Then use original practice questions and a timed question bank with detailed explanations to test whether you can choose the best Scrum.org Professional Scrum Master II (PSM II) answer under realistic scenario pressure.

Continue in PM Mastery

Use this Quick Review as a final concept map, then move into PM Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original PM Mastery practice items; they are not official Scrum.org questions, copied live-exam content, or exam dumps.