PSM II — Scrum.org Professional Scrum Master II Exam Blueprint

How to Use This Exam Blueprint

Use this checklist as a practical study map for the Scrum.org Professional Scrum Master II (PSM II) exam. It is designed for candidates who already know Scrum terminology and need to test whether they can apply Scrum Master judgment in realistic, ambiguous situations.

For each area:

1. Read the readiness target.
2. Mark the items you can explain without notes.
3. Practice scenario decisions: what to do next, what to inspect, who owns the decision, and what artifact or event is affected.
4. Revisit weak areas in the Scrum Guide and with scenario-based practice.

This page is independent exam-prep support and is not affiliated with Scrum.org.

PSM II readiness at a glance

PSM II preparation should go beyond memorizing Scrum terms. You should be ready to reason through team dynamics, organizational impediments, product value, empiricism, and coaching choices.

Core “can you do this?” checklist

Use this as a quick diagnostic. If you hesitate on several items, slow down and review the related topic area.

Scrum theory and mindset

• Explain Scrum as a framework for solving complex problems, not a complete project management methodology.
• Connect empiricism to transparency, inspection, and adaptation.
• Identify when a team is using Scrum terms but not gaining empirical control.
• Explain why transparency must apply to work, progress, quality, goals, and impediments.
• Describe how Scrum values support effective Scrum behavior.
• Recognize when a “best practice” conflicts with empiricism or self-management.
• Explain why Scrum does not guarantee outcomes, but improves learning and adaptation.
• Distinguish complicated work from complex work in scenario decisions.

Scrum accountabilities

• Explain the Product Owner’s accountability for maximizing value.
• Explain the Developers’ accountability for creating a usable Increment and managing the Sprint Backlog.
• Explain the Scrum Master’s accountability for establishing Scrum as defined and helping everyone understand theory and practice.
• Explain the Scrum Team’s shared responsibility for creating value each Sprint.
• Identify when management, stakeholders, or a Scrum Master are improperly taking over Product Owner or Developer decisions.
• Recognize when “team empowerment” is being undermined by hidden approval gates.
• Decide when to coach the Product Owner, the Developers, the whole Scrum Team, or the organization.

Events, artifacts, and commitments

• Explain the purpose of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
• Identify misuse of events, such as status reporting, approval meetings, or design handoffs.
• Explain how the Sprint Goal guides work during the Sprint.
• Connect Product Goal to Product Backlog ordering and long-term focus.
• Explain how the Definition of Done supports transparency and releasability.
• Recognize when an Increment is not truly usable.
• Identify which Scrum artifact needs more transparency in a scenario.
• Explain why artifact transparency is required for meaningful inspection and adaptation.

Scrum framework readiness

Scrum theory and empirical control

Scrum values in applied scenarios

You should be able to use Scrum values as decision filters, not just definitions.

Accountabilities and ownership checks

Event-by-event checklist

Sprint Planning

• Can you explain how the team creates a shared understanding of why the Sprint is valuable?
• Can you distinguish Product Backlog selection from a top-down assignment of scope?
• Can you identify when Sprint Planning is weakened by unclear Product Backlog items?
• Can you explain how capacity, past performance, Definition of Done, and the Sprint Goal inform planning?
• Can you respond when management tries to dictate the Sprint Backlog?
• Can you identify when the Sprint Goal is missing, vague, or merely a list of tasks?

Daily Scrum

• Can you explain that the Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog?
• Can you identify when it has become a status meeting for the Scrum Master or management?
• Can you decide how a Scrum Master should help without controlling the event?
• Can you recognize impediments that need action outside the Daily Scrum?
• Can you distinguish useful daily planning from micromanagement?
• Can you handle scenarios where the team says the Daily Scrum is unnecessary?

Sprint Review

• Can you explain Sprint Review as an inspection and adaptation event focused on the product and future direction?
• Can you recognize when it has become a demo-only meeting or approval gate?
• Can you identify missing stakeholders or missing product evidence.
• Can you connect feedback from the Sprint Review to Product Backlog adaptation.
• Can you respond when stakeholders demand scope changes that threaten focus or quality.
• Can you explain how product value, market feedback, and progress toward goals should be discussed.

Sprint Retrospective

• Can you explain how the Scrum Team inspects its effectiveness and plans improvements?
• Can you recognize when the retrospective is superficial, unsafe, skipped, or dominated by blame?
• Can you help the team select actionable improvements rather than broad complaints?
• Can you distinguish team process improvements from organizational impediments.
• Can you identify when the Definition of Done should be improved.
• Can you support continuous improvement without forcing the team’s decisions.

Artifact and commitment checklist

Artifact scenario prompts

• If stakeholders do not understand progress, which artifact lacks transparency?
• If the team completes tasks but delivers no usable Increment, what does that reveal about Done?
• If the Sprint becomes a set of unrelated tickets, what is wrong with the Sprint Goal?
• If the Product Owner cannot explain ordering decisions, what product-value conversation is missing?
• If multiple teams produce inconsistent quality, what shared understanding may be missing?
• If the Product Backlog is full of stale items, what inspection and adaptation should happen?

Scrum Master service areas

Service to the Scrum Team

Service to the Product Owner

Service to the organization

Coaching, facilitation, teaching, and mentoring

PSM II scenarios often test which stance fits the problem. Do not assume every situation requires the Scrum Master to “fix” the issue directly.

Facilitation readiness checklist

• Can you create a safe environment for difficult inspection?
• Can you keep an event aligned to its purpose without controlling the outcome?
• Can you help quieter voices contribute?
• Can you surface assumptions and decision criteria?
• Can you distinguish conflict about ideas from personal conflict?
• Can you help the group produce a clear next step?
• Can you prevent facilitation from becoming command-and-control leadership?

Scenario decision-point checks

“What should the Scrum Master do next?”

When a question asks what the Scrum Master should do next, look for the least controlling action that increases transparency, learning, and ownership.

Artifact update decisions

Quality, Done, and technical excellence

PSM II candidates should be ready for quality scenarios. The key issue is usually transparency, not just defect count.

Quality readiness prompts

• Can you explain why incomplete work should not be treated as a Done Increment?
• Can you handle pressure to lower quality without becoming confrontational or passive?
• Can you connect technical practices to empirical product management?
• Can you identify when defects are a symptom of poor Definition of Done transparency?
• Can you distinguish technical debt as a product risk, not merely a developer concern?

Product value, stakeholders, and outcomes

Value-readiness checklist

• Can you explain how the Scrum Master supports value delivery without becoming the Product Owner?
• Can you help the Product Owner improve Product Backlog transparency.
• Can you recognize when stakeholders are measuring activity instead of outcomes.
• Can you distinguish output, outcome, impact, and learning.
• Can you support empirical product planning using feedback from Sprint Reviews.
• Can you identify when the Product Goal is unclear or disconnected from Product Backlog ordering.
• Can you handle stakeholder pressure for fixed scope while preserving transparency.
• Can you support conversations about risk, value, cost of delay, learning, and trade-offs.

Stakeholder scenario cues

Forecasting, planning, schedule, and budget judgment

PSM II scenarios may include schedule pressure, budget expectations, or portfolio constraints. The key is to preserve empirical planning rather than pretending uncertainty does not exist.

Metrics readiness checklist

• Can you explain the difference between useful evidence and vanity metrics?
• Can you identify when metrics are being used to control individuals.
• Can you interpret trends without assuming they prove causation.
• Can you use metrics to start inspection, not end the conversation.
• Can you connect metrics to goals, quality, flow, value, and stakeholder learning.
• Can you recognize when velocity, utilization, or output counts are being misused.

Risk, change, and impediments

Risk and change checklist

• Can you explain how Scrum reduces risk through frequent inspection and adaptation?
• Can you identify risks hidden by poor transparency.
• Can you respond when change is treated as failure instead of learning.
• Can you distinguish product risk, technical risk, organizational risk, and delivery risk.
• Can you help the Product Owner order work to address risk and value.
• Can you coach stakeholders on adapting plans based on evidence.
• Can you identify when an impediment requires organizational action.
• Can you avoid solving every team problem yourself when the team can self-manage.

Impediment triage

Agile, predictive, and hybrid environment readiness

The PSM II exam identity is Scrum-focused, but scenarios may involve organizations that use traditional governance, phase gates, annual budgets, matrix management, or mixed delivery models. Be ready to apply Scrum principles without becoming rigid or careless.

Common weak areas and traps

PSM II scenario reasoning workflow

Use this decision path when practicing scenario questions.

    flowchart TD
	    A[Read the scenario] --> B{What is the real problem?}
	    B --> C[Transparency gap]
	    B --> D[Accountability confusion]
	    B --> E[Weak inspection or adaptation]
	    B --> F[Organizational impediment]
	    B --> G[Quality or Done issue]
	
	    C --> H[Make work, progress, risk, or quality visible]
	    D --> I[Respect Scrum accountabilities]
	    E --> J[Refocus event, artifact, or feedback loop]
	    F --> K[Expose impact and engage organization]
	    G --> L[Inspect Definition of Done and Increment]
	
	    H --> M{What should the Scrum Master do?}
	    I --> M
	    J --> M
	    K --> M
	    L --> M
	
	    M --> N[Teach, coach, facilitate, mentor, or remove impediment]
	    N --> O[Preserve empiricism and self-management]

Final-week checklist

Framework and concept review

• Re-read the Scrum Guide carefully and compare every weak area to the actual framework.
• Review Scrum accountabilities until you can identify ownership quickly.
• Review every Scrum event by purpose, participants, outcomes, and common misuse.
• Review artifacts and commitments as transparency tools, not documents to complete.
• Review Scrum values as practical behavior guides.
• Review Definition of Done, Increment, releasability, and quality transparency.

Scenario practice

• Practice questions that ask “what should the Scrum Master do next?”
• For every missed question, write the underlying issue: transparency, accountability, empiricism, quality, value, or impediment.
• Practice choosing between coaching, teaching, mentoring, facilitating, and direct impediment removal.
• Practice stakeholder-pressure scenarios.
• Practice Product Owner support scenarios without taking over Product Owner accountability.
• Practice team-dynamics scenarios where the Scrum Master must avoid command-and-control behavior.
• Practice organizational-change scenarios involving managers, governance, dependencies, and metrics.

Final readiness questions

• Can you answer scenario questions without relying on role stereotypes?
• Can you explain why an answer improves empiricism?
• Can you identify the accountable person or group before choosing an action?
• Can you reject answers that create false transparency?
• Can you preserve self-management while still being an active Scrum Master?
• Can you handle quality pressure without compromising Done?
• Can you connect product decisions to value, goals, feedback, and risk?
• Can you explain why “doing Scrum events” is not the same as using Scrum effectively?

Practical next step

Choose three weak areas from this checklist and practice them with scenario questions. For each scenario, force yourself to name:

1. The transparency gap or decision point.
2. The Scrum accountability involved.
3. The artifact, event, or commitment affected.
4. The best Scrum Master stance: teach, coach, facilitate, mentor, or remove an impediment.
5. The trap answer you must avoid.

When you can do that consistently, you are closer to PSM II-ready judgment rather than simple Scrum recall.