PSM II — Scrum.org Professional Scrum Master II Cheat Sheet

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

PSM II exam mindset

This Cheat Sheet is independent review support for candidates preparing for the Scrum.org Professional Scrum Master II (PSM II) exam. PSM II scenarios usually test whether you can apply Scrum principles in messy organizational situations, not just recall definitions.

Core Scrum principles to apply

Scrum values reference

Scrum accountabilities

Scrum Master stance selector

Events: purpose, ownership, and traps

Artifacts and commitments

Sprint Goal, forecast, and scope

Definition of Done and quality

Product Backlog and refinement

Product Owner coaching reference

Developer self-management reference

“What should the Scrum Master do next?” decision table

Facilitation quick reference

Coaching, mentoring, teaching, and advising

Organizational service by the Scrum Master

Metrics and evidence

Use metrics to improve transparency and decision-making. Do not weaponize them.

Empirical forecasting vs fixed planning

Multiple Scrum Teams on one product

Agile vs Scrum distinctions

Common anti-patterns and corrections

Scenario shortcuts

When work is not Done

Ask:

1. Does it meet the Definition of Done?
2. Is the DoD transparent and sufficient?
3. Are Developers able to build quality in?
4. Are there systemic impediments such as tooling, skills, architecture, or policy?
5. Is pressure to deliver scope causing quality compromise?

Best answer usually improves transparency and quality rather than reclassifying unfinished work.

When stakeholders are unhappy

1. Were they involved at Sprint Review and throughout discovery?
2. Is Product Goal clear?
3. Is Product Backlog ordered by value and evidence?
4. Is the PO empowered and available?
5. Is the Increment revealing learning that should adapt direction?

Best answer usually improves collaboration and empirical product decisions rather than adding approval layers.

When the team is “not following Scrum”

1. Is the issue lack of knowledge, skill, motivation, or organizational constraint?
2. Which Scrum accountability is unclear?
3. Which artifact or event lacks transparency?
4. What adaptation is missing?
5. Should the Scrum Master teach, coach, facilitate, or remove an impediment?

Best answer usually starts by making the problem visible and helping accountable people solve it.

When management wants control

1. What decision does management need to make?
2. Which Scrum artifacts provide evidence?
3. Is the request improving transparency or creating command-and-control?
4. Are incentives or policies undermining Scrum?
5. Can the Scrum Master coach management toward empirical governance?

Best answer usually respects management’s need for information while preserving Scrum accountabilities.

Fast “choose the better answer” rules

Final readiness checklist

Before taking Scrum.org Professional Scrum Master II (PSM II), be able to answer scenario questions by identifying:

• The relevant Scrum accountability: Scrum Master, Product Owner, Developers, or Scrum Team.
• Which artifact or commitment lacks transparency.
• Which event should inspect and adapt the situation.
• Whether the Scrum Master should teach, coach, facilitate, mentor, or remove an impediment.
• Whether the proposed answer protects self-management and empiricism.
• Whether “Done” is real or partially complete work is being disguised.
• Whether a metric is being used for learning or control.
• Whether the Product Owner is accountable for value and Product Backlog ordering.
• Whether Developers are accountable for quality, sizing, Sprint Backlog, and the usable Increment.
• Whether the organization needs coaching because a systemic impediment is outside the team’s control.

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.

The Scrum Master stance: choose the right intervention

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

    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

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.

• 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.

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.

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

Evidence-based product thinking

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

• 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.

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.

• 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: 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?

Practice next

After this Cheat Sheet, 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.

Put the review into practice