PSM II exam mindset
This Quick Reference 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.
| Exam pattern | High-yield response style |
|---|
| Scenario has pressure to “manage” the team | Preserve Scrum accountabilities and self-management. Coach, facilitate, make transparency possible. |
| Stakeholders demand commitments, dates, or control | Use empiricism: inspect real progress, adapt forecasts, protect transparency. |
| Team is not producing Done increments | Focus on Definition of Done, quality, technical practices, impediments, and Sprint Goal clarity. |
| Product Owner is absent or ineffective | Coach the Product Owner and organization. Do not silently replace the PO. |
| Organization adds roles, gates, reports, or approvals | Ask whether they improve transparency and value or obscure Scrum accountabilities. |
| Multiple answers seem reasonable | Prefer the answer that strengthens empiricism, accountability, Scrum values, and long-term effectiveness. |
Core Scrum principles to apply
| Principle | What it means in PSM II scenarios | Common trap |
|---|
| Empiricism | Decisions are based on transparency, inspection, and adaptation. | Using plans, estimates, or status reports as substitutes for real Done increments. |
| Transparency | Work, progress, quality, impediments, and goals are visible and understandable. | Hiding unfinished work, technical debt, risks, or missed forecasts to “look agile.” |
| Inspection | Scrum events and artifacts expose reality frequently. | Treating events as ceremonies with no adaptation. |
| Adaptation | Scrum Team changes direction, plan, practices, or backlog based on what is learned. | Continuing the plan because it was approved earlier. |
| Self-management | Scrum Team decides who does what, when, and how within Scrum accountabilities. | Scrum Master, manager, architect, or Product Owner assigning tasks to Developers. |
| Value focus | Product decisions are guided by value, outcomes, risk, and learning. | Optimizing utilization, velocity, or output volume without validating value. |
Scrum values reference
| Scrum value | Practical meaning | Scenario signal |
|---|
| Commitment | Commit to goals, quality, learning, and professionalism. | Sprint Goal and Definition of Done matter more than “committing” to every backlog item. |
| Focus | Concentrate on Sprint work and goals. | Avoid mid-Sprint noise that endangers the Sprint Goal. |
| Openness | Make progress, problems, risk, and quality visible. | Do not hide undone work, defects, or stakeholder dissatisfaction. |
| Respect | Trust professionals to make decisions within their accountabilities. | Avoid command-and-control task assignment. |
| Courage | Address hard problems and organizational impediments. | Scrum Master challenges harmful policies, fake transparency, and low quality. |
Scrum accountabilities
| Accountability | Owns / is accountable for | Does not mean | PSM II decision point |
|---|
| Scrum Master | Establishing Scrum as defined in the Scrum Guide; improving Scrum Team effectiveness; serving Scrum Team, Product Owner, and organization. | Project manager, team boss, secretary, delivery enforcer, or process police. | Coach, facilitate, teach, remove systemic impediments, and help others fulfill their accountabilities. |
| Product Owner | Maximizing product value; effective Product Backlog management; Product Goal clarity; Product Backlog ordering. | Committee chair, requirements clerk, proxy for every stakeholder, or task assigner. | If value, ordering, stakeholder alignment, or Product Goal is weak, coach the PO rather than taking over. |
| Developers | Creating a usable Done Increment each Sprint; Sprint Backlog; sizing; planning work; quality. | Only coders, subordinates, or people who wait for assigned tasks. | If work execution or quality is weak, help Developers self-manage and improve engineering practices. |
| Scrum Team | Delivering valuable, useful increments; working toward Product Goal; collaborating across accountabilities. | Separate business, analysis, design, test, and release departments passing work along. | Optimize the whole Scrum Team, not local roles or silos. |
Scrum Master stance selector
| Situation | Best Scrum Master stance | Avoid |
|---|
| Team does not understand Scrum | Teach Scrum theory, rules, accountabilities, and purpose. | Letting “our version of Scrum” undermine empiricism. |
| Team can solve its own problem | Coach with questions; encourage self-management. | Solving every problem for the team. |
| Event lacks focus or collaboration | Facilitate structure, purpose, participation, and outcomes. | Owning all discussion or decisions. |
| Organizational policy blocks agility | Lead change; make impact visible; work with management to remove impediments. | Telling the team to “work around it” forever. |
| PO struggles with value or backlog | Mentor and coach PO on Product Goal, ordering, stakeholder collaboration, and transparency. | Acting as Product Owner. |
| Developers struggle with quality | Encourage technical excellence, Definition of Done, automation, pairing, refactoring, and learning. | Accepting “undone” work as normal. |
| Conflict is productive but tense | Facilitate respectful inspection and decision-making. | Suppressing disagreement to keep harmony. |
| Conflict becomes personal or unsafe | Intervene to restore respect and openness. | Ignoring it as “self-management.” |
Events: purpose, ownership, and traps
| Event | Purpose | Key participants | Timebox guidance | PSM II traps |
|---|
| Sprint | Container for all other events; creates consistency and enables inspection/adaptation. | Scrum Team | One month or less. | Treating Sprint as a mini-waterfall phase; changing work freely without regard to Sprint Goal. |
| Sprint Planning | Decide why the Sprint is valuable, what can be Done, and how work will be approached. | Scrum Team | Up to 8 hours for a one-month Sprint. | PO dictates scope; Developers are forced to “commit” to all selected PBIs; Sprint Goal is skipped. |
| Daily Scrum | Developers inspect progress toward Sprint Goal and adapt Sprint Backlog. | Developers; PO/SM attend if working as Developers or as useful participants. | 15 minutes. | Status meeting for Scrum Master; manager assigns work; no adaptation occurs. |
| Sprint Review | Inspect Increment and progress toward Product Goal; adapt Product Backlog with stakeholders. | Scrum Team and stakeholders. | Up to 4 hours for a one-month Sprint. | Demo-only meeting; approval gate; stakeholders absent; no backlog adaptation. |
| Sprint Retrospective | Inspect people, interactions, processes, tools, and Definition of Done; plan improvements. | Scrum Team | Up to 3 hours for a one-month Sprint. | Optional when busy; complaint session without action; avoids quality problems. |
Event decision cues
| If the question says… | Think… | Strong answer direction |
|---|
| “The Daily Scrum is not useful” | Is it inspecting progress toward the Sprint Goal? | Teach purpose; let Developers choose format; focus on adaptation. |
| “Stakeholders are surprised at the Review” | Transparency and collaboration were too late. | Involve stakeholders earlier and use Review to inspect/adapt, not just present. |
| “Sprint Planning takes too long” | Product Backlog may not be refined enough; Sprint Goal may be unclear. | Improve refinement and PO/Developer collaboration before planning. |
| “Retrospectives produce no change” | Adaptation is missing. | Help select actionable improvements and make them visible in the Sprint Backlog when appropriate. |
| “Management wants a status meeting” | Scrum artifacts/events should provide transparency. | Use Product/Sprint Backlogs, Increment, and forecasts; avoid duplicate command-reporting systems. |
Artifacts and commitments
| Artifact | Commitment | Purpose | Who is accountable? | Common exam distinction |
|---|
| Product Backlog | Product Goal | Ordered, emergent list of what is needed to improve the product. | Product Owner accountable for effective management and ordering. | Product Backlog is the single source of work undertaken by the Scrum Team. |
| Sprint Backlog | Sprint Goal | Plan by and for Developers for achieving the Sprint Goal. | Developers. | Sprint Backlog is adaptive; Developers update it as more is learned. |
| Increment | Definition of Done | Concrete step toward Product Goal; usable when Done. | Scrum Team creates it; Developers accountable for quality. | Work not meeting DoD is not part of the Increment. |
Commitment distinctions
| Commitment | What it stabilizes | What can still change |
|---|
| Product Goal | Strategic direction for the Product Backlog. | Product Backlog items, ordering, implementation options. |
| Sprint Goal | Objective for the Sprint and focus for adaptation. | Scope details and Sprint Backlog plan, if Sprint Goal remains achievable. |
| Definition of Done | Quality transparency and releasability of Increment. | Practices can improve; quality criteria should not be weakened to meet dates. |
Sprint Goal, forecast, and scope
| Concept | Correct interpretation | Trap |
|---|
| Sprint Goal | The Scrum Team’s objective for the Sprint. It provides focus and flexibility. | Treating the Sprint Goal as a list of all selected Product Backlog items. |
| Sprint forecast | Developers’ forecast of what they believe can be Done. | Treating forecast as a fixed promise or contract. |
| Sprint Backlog | Developers’ plan for achieving the Sprint Goal. | Treating it as a task list assigned by PO, SM, or manager. |
| Scope change during Sprint | Possible when PO and Developers collaborate and the Sprint Goal is not endangered. | Freezing all details regardless of learning, or changing work so much that the goal becomes meaningless. |
| Sprint cancellation | Product Owner may cancel if Sprint Goal becomes obsolete. | Scrum Master or stakeholders canceling because progress is uncomfortable. |
Definition of Done and quality
| Situation | Correct PSM II reasoning |
|---|
| Work is coded but not tested | It is not Done unless it meets the Definition of Done. Do not count it in the Increment. |
| Team wants to lower quality to finish more items | Quality does not decrease to meet dates. Inspect why capacity, skills, refinement, or architecture are insufficient. |
| Multiple Scrum Teams work on one product | They need a shared Definition of Done sufficient for integrated increments. |
| Organization has a DoD standard | Scrum Teams must follow at least the organizational standard. They may make it stricter. |
| No organizational DoD exists | Scrum Team creates one appropriate for the product. |
| Defects appear after release | Inspect DoD, technical practices, test strategy, and transparency. Do not normalize escaped defects. |
| Technical debt slows delivery | Make it visible; consider Product Backlog items, DoD improvements, refactoring, automation, and stakeholder conversations about value/risk. |
Product Backlog and refinement
| Topic | Quick reference |
|---|
| Product Backlog ordering | Product Owner is accountable. Ordering may consider value, risk, dependencies, learning, cost of delay, and stakeholder needs. |
| Refinement | Ongoing activity to add detail, split items, estimate, and improve understanding. It is not a formal Scrum event. |
| Sizing | Developers who will do the work are responsible for estimates/sizing. |
| “Ready” items | Scrum does not require a formal Definition of Ready. Items selected for a Sprint should be sufficiently understood to be completed within the Sprint. |
| Stakeholder input | Important, but stakeholders do not overrule PO accountability for ordering. |
| Dependencies | Make visible and reduce them where possible; do not hide them in plans. |
| Product Goal | Gives Product Backlog a coherent direction and enables strategic inspection. |
Product Owner coaching reference
| PO problem | Scrum Master response | Avoid |
|---|
| PO unavailable | Coach PO and organization on PO accountability and impact of absence. Help create transparency. | Becoming proxy PO without addressing root cause. |
| PO orders by stakeholder pressure only | Coach value-based ordering, Product Goal, evidence, and stakeholder collaboration. | Letting loudest stakeholder own Product Backlog. |
| PO writes everything alone | Encourage collaboration with Developers and stakeholders. | Making refinement a PO handoff process. |
| PO dictates technical solution | Clarify PO owns value/ordering; Developers own how work is done. | Turning Developers into order-takers. |
| PO refuses to attend events | Explain purpose and consequences; involve organization if accountability cannot be fulfilled. | Running events as if PO input is optional for product decisions. |
| PO wants exact long-term commitment | Use empirical forecasting, transparency, and incremental delivery. | Presenting estimates as guarantees. |
Developer self-management reference
| Scenario | Strong answer |
|---|
| Developers wait for tasks | Coach self-management; Daily Scrum should adapt Sprint Backlog and coordinate work. |
| One senior person assigns all work | Facilitate conversation about shared ownership, skills, and self-management. |
| Specialists create handoffs | Encourage cross-functionality, swarming, pairing, skill growth, and Done increments. |
| Developers ignore PO | Reinforce Scrum Team collaboration; Developers need PO input for value and ordering. |
| Developers overcommit | Improve forecasting, refinement, Sprint Goal focus, and transparency. |
| Developers skip testing | Definition of Done and quality accountability are non-negotiable. |
“What should the Scrum Master do next?” decision table
| Scenario signal | Best next move | Usually wrong |
|---|
| Team hides unfinished work | Increase transparency; clarify Done; inspect causes. | Count partial work as Done. |
| Stakeholder asks Scrum Master for delivery commitment | Redirect to Product Owner for product decisions and Developers for forecasts; support transparency. | Commit on behalf of the Scrum Team. |
| Manager assigns work to Developers | Coach manager and team on Scrum accountabilities and self-management. | Accept it to avoid conflict. |
| Team wants to cancel Daily Scrum | Teach purpose; help Developers make it useful. | Cancel it because “the team is mature.” |
| Sprint Goal is obsolete | Product Owner considers cancellation. | Scrum Master cancels Sprint. |
| Team misses forecast repeatedly | Inspect causes: refinement, interruptions, dependencies, skills, quality, estimation, Sprint Goal. | Punish team or force larger commitments. |
| PO demands more work mid-Sprint | PO and Developers discuss impact; adapt only if Sprint Goal remains protected. | Scrum Master accepts change and assigns tasks. |
| Organization requires phase-gate approval before release | Make delay and risk visible; coach organization toward empirical release governance. | Hide Scrum increments until gate approves them. |
| Technical debt is invisible to stakeholders | Make impact transparent in value/risk terms. | Treat it as only an internal developer concern. |
| Retrospective action items never happen | Select fewer, clearer improvements; place improvement work in Sprint Backlog when useful. | Create a long improvement list with no ownership. |
Facilitation quick reference
| Facilitation need | Practical technique | Exam caution |
|---|
| Unclear event purpose | Restate event goal and desired outcome. | Do not let events become generic meetings. |
| Dominant voice | Use structured turn-taking, silent writing, or explicit working agreements. | Scrum Master should not dominate in response. |
| Passive group | Ask open questions tied to Sprint Goal, Product Goal, value, and Done. | Avoid solving the problem for the team by default. |
| Decision paralysis | Clarify who owns the decision and what information is needed. | Consensus is useful but not required for every accountability decision. |
| Conflict | Separate people from problem; make facts and assumptions visible. | Avoid false harmony that hides real impediments. |
| Remote/hybrid event | Make artifacts visible; improve participation and transparency. | Do not measure success by attendance alone. |
Coaching, mentoring, teaching, and advising
| Intervention | Use when… | Example |
|---|
| Teaching | People lack Scrum understanding. | Explain why Daily Scrum is for Developers to inspect progress toward Sprint Goal. |
| Mentoring | Someone needs experience-based guidance. | Help a new Scrum Master think through organizational impediments. |
| Coaching | Person/team can discover their own solution. | Ask Developers what prevents them from delivering Done increments. |
| Facilitation | Group needs help collaborating or deciding. | Facilitate Sprint Retrospective to produce one actionable improvement. |
| Advising/consulting | Expert input is needed and requested. | Suggest options for making technical debt visible. |
| Impediment removal | Blocker is outside team’s control or systemic. | Work with management to change policy that prevents continuous integration. |
Organizational service by the Scrum Master
| Area | Scrum Master serves by… | PSM II trap |
|---|
| Scrum adoption | Helping plan, advise, and implement Scrum effectively. | Mandating rituals without changing accountabilities. |
| Management | Coaching leaders on empiricism, self-management, and removing impediments. | Treating managers as irrelevant. |
| Stakeholders | Helping them understand empirical product development and Sprint Review. | Letting stakeholders bypass Product Owner or disrupt Sprint focus. |
| HR / performance systems | Making impact of individual utilization targets or role silos visible. | Accepting incentives that undermine teamwork. |
| Governance | Supporting transparency through increments, evidence, and forecasts. | Creating heavyweight reports that hide reality. |
| Culture | Encouraging openness, respect, experimentation, and continuous improvement. | Confusing “servant leadership” with passivity. |
Metrics and evidence
Use metrics to improve transparency and decision-making. Do not weaponize them.
| Metric / evidence | Useful for | Dangerous when used as… |
|---|
| Done Increment | Best evidence of progress and quality. | Ignored in favor of percent-complete reporting. |
| Sprint Goal achievement | Inspecting focus and outcome. | Punishing teams for learning or adapting. |
| Velocity / throughput | Short-term forecasting by a stable team. | Productivity target, comparison across teams, or management quota. |
| Lead time / cycle time | Flow and responsiveness. | Blame metric for individuals. |
| Defect trends | Quality transparency and DoD improvement. | Reason to add separate test phase instead of improving built-in quality. |
| Customer/stakeholder feedback | Value and product direction. | A replacement for PO accountability. |
| Technical debt indicators | Ability to sustain delivery. | Hidden from Product Backlog/value conversations. |
| Outcome measures | Whether product changes achieve desired effects. | Ignored while optimizing output volume. |
Empirical forecasting vs fixed planning
| Need | Scrum-consistent approach | Avoid |
|---|
| Release forecast | Use Product Backlog ordering, team history, known capacity, risks, and transparency. Update often. | Treating early estimates as guarantees. |
| Budget discussion | Provide ranges, assumptions, options, and empirical updates. | Pretending uncertainty does not exist. |
| Stakeholder deadline | Discuss trade-offs in scope, value, risk, and quality. Quality should not be reduced. | Committing to all scope by fixed date without evidence. |
| Long-term roadmap | Use Product Goal, evidence, and adaptation. | Locking detailed requirements far in advance. |
| Progress reporting | Show Done increments, backlog adaptation, risks, and forecasts. | Percent complete on partially done work. |
Multiple Scrum Teams on one product
| Topic | Correct reference |
|---|
| Product | One product should have one Product Backlog. |
| Product Owner | One Product Owner is accountable for Product Backlog ordering and value. |
| Increment | Work must integrate into a single Done Increment. |
| Definition of Done | Teams working on the same product need a shared DoD adequate for integrated quality. |
| Coordination | Prefer team-to-team collaboration, shared refinement, integration practices, and transparency. |
| Dependencies | Reduce through feature teams, cross-functionality, architecture improvements, and ordering choices. |
| Trap | Creating separate component backlogs, separate Product Owners, or late integration hides risk. |
Agile vs Scrum distinctions
| Statement | PSM II interpretation |
|---|
| “Scrum is just meetings.” | Events are formal inspection/adaptation opportunities tied to artifacts and commitments. |
| “Agile means no planning.” | Scrum includes planning every Sprint and ongoing Product Backlog refinement, but plans are adaptive. |
| “Self-managing means no management.” | Management still sets context, strategy, constraints, and removes organizational impediments. |
| “Velocity measures team performance.” | Velocity may support forecasting; it is not a value or productivity measure. |
| “The Scrum Master protects the team from stakeholders.” | Scrum Master helps create effective collaboration while protecting Sprint focus and Scrum accountabilities. |
| “The Product Owner must write every backlog item.” | PO is accountable for effective backlog management, but work may be delegated. |
| “Done means accepted by PO.” | Done means meeting the Definition of Done. PO feedback matters, but acceptance is not a substitute for DoD. |
Common anti-patterns and corrections
| Anti-pattern | Why it fails | Better response |
|---|
| Scrum Master assigns tasks | Breaks Developer self-management. | Developers plan and manage Sprint Backlog. |
| PO absent from Sprint Planning | Weakens value, goal, and scope decisions. | Coach PO accountability; ensure collaboration. |
| Daily Scrum reports to Scrum Master | Reduces inspection/adaptation by Developers. | Focus on progress toward Sprint Goal. |
| Sprint Review as final approval | Delays feedback and confuses Done with approval. | Inspect Increment and adapt Product Backlog. |
| Retrospective skipped | Removes formal process adaptation. | Keep it and make it actionable. |
| Separate hardening Sprint | Indicates Done is incomplete. | Improve DoD and engineering practices. |
| “Almost done” counted as progress | Reduces transparency. | Only Done increments count as product progress. |
| Stakeholders reorder Sprint Backlog | Confuses accountabilities. | PO orders Product Backlog; Developers manage Sprint Backlog. |
| Manager compares team velocities | Encourages gaming and local optimization. | Use metrics for team improvement and forecasting only. |
| Definition of Ready as mandatory gate | Can become mini-waterfall and block adaptation. | Use refinement practices without overriding Scrum. |
Scenario shortcuts
When work is not Done
Ask:
- Does it meet the Definition of Done?
- Is the DoD transparent and sufficient?
- Are Developers able to build quality in?
- Are there systemic impediments such as tooling, skills, architecture, or policy?
- Is pressure to deliver scope causing quality compromise?
Best answer usually improves transparency and quality rather than reclassifying unfinished work.
When stakeholders are unhappy
Ask:
- Were they involved at Sprint Review and throughout discovery?
- Is Product Goal clear?
- Is Product Backlog ordered by value and evidence?
- Is the PO empowered and available?
- 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”
Ask:
- Is the issue lack of knowledge, skill, motivation, or organizational constraint?
- Which Scrum accountability is unclear?
- Which artifact or event lacks transparency?
- What adaptation is missing?
- 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
Ask:
- What decision does management need to make?
- Which Scrum artifacts provide evidence?
- Is the request improving transparency or creating command-and-control?
- Are incentives or policies undermining Scrum?
- 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
| Prefer answers that… | Be skeptical of answers that… |
|---|
| Strengthen transparency, inspection, and adaptation. | Hide uncertainty or unfinished work. |
| Respect Scrum accountabilities. | Add unofficial roles that take over PO, SM, or Developer accountability. |
| Help the team self-manage. | Assign work, enforce commitments, or centralize decisions in Scrum Master. |
| Use Done increments as evidence. | Use percent complete as proof of progress. |
| Coach the organization, not just the team. | Blame Developers for systemic impediments. |
| Protect quality and Definition of Done. | Lower quality to meet dates or scope. |
| Treat Sprint Goal as the commitment. | Treat all selected backlog items as fixed scope. |
| Involve stakeholders through Sprint Review and PO collaboration. | Let stakeholders bypass the PO or control Developers directly. |
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.
Practical next step
Use this Quick Reference to review weak areas, then practice with scenario-based questions that force you to choose the best Scrum Master action, explain why weaker options violate Scrum accountabilities, and connect each answer back to empiricism, self-management, Scrum values, and the Definition of Done.