PSM I Syllabus — Learning Objectives by Domain

Use this syllabus as your checklist. Drill right after each section and keep a miss log of “why the best answer is best.”

What’s covered

• Scrum Theory, Values, and Empiricism (15%)
• Scrum Team and Accountabilities (25%)
• Scrum Events and Timeboxes (25%)
• Artifacts, Commitments, and Done (25%)
• Applying Scrum in Practice (10%)

Scrum Theory, Values, and Empiricism (15%)

Empiricism and Lean Thinking

• Explain why Scrum is designed for complex work and why prediction is limited in complex domains.
• Define empiricism and describe how it supports decision-making under uncertainty.
• Identify the three pillars of empiricism (transparency, inspection, adaptation) and their intent.
• Distinguish transparency from reporting and identify what must be visible for meaningful inspection.
• Select an appropriate inspection point in Scrum for a given uncertainty or risk.
• Choose an adaptation action that changes plan or approach based on new evidence.
• Describe Lean thinking principles that show up in Scrum (focus on value, reduce waste, fast feedback).
• Recognize batch-size and handoff waste in a workflow and choose a Scrum-aligned correction.
• Identify when optimizing a local activity harms overall value delivery and choose a systems-oriented adjustment.
• Explain why a Done Increment each Sprint reduces risk compared to partial or hidden work.

Scrum Values and Team Behavior

• Name the five Scrum values and explain why they matter for successful Scrum.
• Recognize behaviors that violate the Scrum values and choose an appropriate corrective action.
• Differentiate commitment to the Sprint Goal from committing to a fixed scope or plan.
• Apply focus to decide what to do when new work threatens to distract from the Sprint Goal.
• Use openness to improve transparency without creating blame-oriented dynamics.
• Use respect to handle disagreement while still reaching a workable decision.
• Use courage to surface risks or impediments early and propose a constructive response.
• Identify when psychological safety is low and choose facilitation actions that increase openness.
• Choose a way to address low trust between roles while preserving accountabilities.
• Select feedback behaviors that promote learning and adaptation rather than defensiveness.

Scrum Framework Basics

• Explain the purpose of Scrum as a framework rather than a complete process.
• Identify the three Scrum artifacts and what each makes transparent.
• Identify the five Scrum events and the main inspection/adaptation purpose of each.
• Identify the three Scrum accountabilities and what each is responsible for.
• Distinguish rules of Scrum from optional practices and avoid treating non-Scrum practices as mandatory.
• Recognize when a practice reduces empiricism (for example, hidden work) and choose a Scrum-aligned change.
• Select correct terminology for common concepts (Sprint Goal, Product Goal, Definition of Done).
• Differentiate acceptance criteria from the Definition of Done and explain how they work together.
• Identify what makes Scrum artifacts usable (transparent, understood, and tied to commitments).
• Recognize when Scrum is being used as a label while work is still managed as a phase-gate process.

Transparency, Inspection, and Adaptation in Practice

• Choose what information to visualize to increase transparency (work in progress, blockers, progress to goal).
• Identify when inspection is ineffective because goals or quality criteria are unclear.
• Decide when to adapt the Product Backlog ordering based on new learning.
• Decide when to adapt the Sprint Backlog plan during the Sprint while preserving the Sprint Goal.
• Recognize when adaptation is too slow (waiting for end of project) and choose a Scrum-aligned remedy.
• Recognize when adaptation is too frequent (thrashing) and choose a stabilizing action.
• Select actions that improve transparency of quality (Definition of Done, test results, integration status).
• Identify when stakeholders are surprised at Sprint Review and improve transparency earlier.
• Choose an approach to handle emergent work without hiding it or undermining the Sprint Goal.
• Explain how short timeboxes and frequent inspection points reduce risk in uncertain work.

Common Scrum Misconceptions

• Identify when people are confusing Scrum with a waterfall-in-sprints approach and choose a correction.
• Recognize the anti-pattern of using the Daily Scrum as a status meeting and choose an improvement.
• Recognize when the Sprint Review is treated as a gate and choose a Scrum-aligned alternative.
• Identify misconceptions about the Scrum Master as a manager and restate the correct accountability.
• Identify misconceptions about the Product Owner as a committee and restate the correct accountability.
• Recognize the misconception that the Product Backlog is fixed during a Sprint and state what can change.
• Recognize the misconception that the Sprint Goal cannot be adjusted and state what is allowed.
• Identify when 'definition of done' is being used as a phase checklist and clarify its real intent.
• Recognize when estimates are treated as commitments and choose a healthier Scrum-aligned use.
• Identify when 'velocity targets' are being used to pressure teams and choose a more appropriate approach.

Scrum Team and Accountabilities (25%)

Scrum Team Structure and Self-Management

• Explain what it means for a Scrum Team to be self-managing.
• Explain what it means for a Scrum Team to be cross-functional.
• Recognize when specialization is causing handoffs and choose actions to improve cross-functionality.
• Decide how the Scrum Team should handle external management assigning work during a Sprint.
• Determine who decides how to turn Product Backlog items into a Done Increment.
• Identify when team size or composition is reducing effectiveness and choose an adjustment.
• Recognize when competing responsibilities are reducing focus and propose a mitigation.
• Choose a way to create shared ownership of quality rather than pushing it to a separate group.
• Recognize when a team is not collaborating well and choose a Scrum-aligned improvement.
• Identify when a Scrum Team is not aligned on purpose and choose an action to reinforce goals.

Product Owner Accountability

• State the Product Owner accountability for maximizing product value.
• State the Product Owner accountability for managing the Product Backlog.
• Decide how the Product Owner should order the Product Backlog when stakeholders disagree.
• Select appropriate inputs a Product Owner uses to order the Product Backlog (value, risk, dependencies).
• Explain what it means for Product Backlog items to be transparent and understood.
• Decide how to handle a request to change priorities mid-Sprint.
• Identify when the Product Owner is absent and choose a Scrum-aligned mitigation.
• Recognize when the Product Owner is delegating decisions without accountability and correct it.
• Explain the relationship between Product Goal and Product Backlog ordering.
• Choose how to engage stakeholders so feedback improves the Product Backlog and product value.

Scrum Master Accountability

• State the Scrum Master accountability for establishing Scrum as defined in the Scrum Guide.
• Choose coaching actions a Scrum Master uses to improve Scrum Team effectiveness.
• Choose facilitation actions a Scrum Master uses to make Scrum events effective.
• Identify impediments that are within the Scrum Team's control vs organizational impediments.
• Select an appropriate Scrum Master response when transparency is low or information is hidden.
• Select an appropriate Scrum Master response when stakeholders disrupt the Sprint.
• Recognize when the Scrum Master is acting as a project manager and correct the behavior.
• Help the organization understand Scrum by choosing enabling actions (training, policy changes, support).
• Choose actions to help the Scrum Team focus on creating a Done Increment each Sprint.
• Select actions that encourage empiricism and reduce blame or command-and-control dynamics.

Developers Accountability and Collaboration

• State the Developers accountability for creating a plan for the Sprint (Sprint Backlog).
• State the Developers accountability for instilling quality by adhering to the Definition of Done.
• State the Developers accountability for adapting their plan each day toward the Sprint Goal.
• Decide how Developers should handle unclear Product Backlog items during a Sprint.
• Choose actions Developers can take when they discover work is larger than expected.
• Decide how Developers should respond when asked to skip quality steps to 'go faster'.
• Choose collaboration behaviors that improve flow (swarming, pairing, shared ownership).
• Identify when individual assignments are hurting collaboration and choose a Scrum-aligned correction.
• Decide how Developers should incorporate feedback from Sprint Review into future work.
• Recognize when Developers are over-optimizing for utilization and choose a healthier approach.

Stakeholders and Scrum Team Collaboration

• Define who stakeholders are in Scrum and how they relate to the Product Owner and Scrum Team.
• Choose how to involve stakeholders so feedback is useful and does not derail the Sprint.
• Decide what to do when stakeholders try to directly assign work to Developers.
• Decide how to handle stakeholder requests that conflict with the Product Goal.
• Recognize when stakeholder feedback is too late and select actions to improve feedback timing.
• Choose communication practices that maintain transparency without adding non-Scrum bureaucracy.
• Identify when stakeholder expectations are unmanaged and choose an alignment action.
• Explain how the Sprint Review supports collaboration with stakeholders.
• Choose how to communicate progress using evidence rather than promises or activity metrics.
• Recognize when a stakeholder conflict is harming outcomes and choose a Scrum Master facilitation response.

Scrum Events and Timeboxes (25%)

The Sprint

• Explain the purpose of the Sprint as a container event for all other events.
• Identify what is required for each Sprint (planning, daily, review, retrospective).
• Explain how the Sprint Goal provides cohesion and focus.
• Decide how to handle scope changes during a Sprint while keeping the Sprint Goal intact.
• Identify when a Sprint should be canceled and who can cancel it.
• Describe what happens when a Sprint is canceled and what is done with completed work.
• Recognize when a Sprint is being used as a phase gate and choose a Scrum-aligned correction.
• Choose actions to keep a Sprint timebox stable and avoid extending it for unfinished work.
• Explain why Sprints are kept at consistent length and what risks arise when length changes frequently.
• Recognize when work is being started without a clear Sprint Goal and select a correction.

Sprint Planning

• State the purpose of Sprint Planning and what it produces.
• Explain the three Sprint Planning topics (why, what, how) and their intent.
• Decide how the Sprint Goal is crafted and who collaborates on it.
• Decide how Developers select Product Backlog items for the Sprint.
• Identify the role of the Product Owner during Sprint Planning.
• Determine what inputs are needed for effective Sprint Planning (Product Goal, ordered Product Backlog, capacity).
• Recognize when Sprint Planning is over-detailed and choose a more appropriate approach.
• Decide how to handle new information discovered during Sprint Planning.
• Identify when the Sprint Backlog is unrealistic and choose an adjustment.
• Explain how Sprint Planning supports transparency and reduces risk.

Daily Scrum

• State the purpose of the Daily Scrum and how it supports progress toward the Sprint Goal.
• Recognize when the Daily Scrum is used as a status meeting and choose a correction.
• Decide who must attend the Daily Scrum and who may attend.
• Select an effective Daily Scrum structure and explain why it is valid.
• Decide how Developers should update their plan based on information from the Daily Scrum.
• Recognize when impediments are raised and ignored and choose an appropriate Scrum Master action.
• Decide how to handle work that is blocked during the Sprint.
• Choose how to handle discussions that exceed the Daily Scrum purpose and timebox.
• Identify what should be made transparent during the Daily Scrum (progress, blockers, plan adjustments).
• Explain why the Daily Scrum is for Developers even when others have interest in updates.

Sprint Review

• State the purpose of the Sprint Review and how it supports adaptation of the Product Backlog.
• Identify who participates in the Sprint Review and the role of stakeholders.
• Recognize when a Sprint Review is treated as a sign-off gate and choose a correction.
• Decide what to present at Sprint Review (Done Increment) and what not to present.
• Decide how feedback from Sprint Review should change Product Backlog ordering.
• Recognize when the Increment is not truly Done and choose an appropriate response.
• Decide how to handle stakeholder dissatisfaction discovered at Sprint Review.
• Explain how the Sprint Review supports progress toward the Product Goal.
• Choose how to discuss progress using evidence rather than promises.
• Identify Sprint Review anti-patterns (demo theater, no adaptation) and select corrective actions.

Sprint Retrospective and Improvement

• State the purpose of the Sprint Retrospective and what it should achieve.
• Identify who participates in the Retrospective and why.
• Recognize when the Retrospective becomes complaint-only and choose a facilitation improvement.
• Select improvement actions that are small, actionable, and owned.
• Decide how to incorporate improvement actions into the next Sprint.
• Recognize when improvement actions conflict with the Sprint Goal and choose a balanced approach.
• Explain how the Retrospective supports adaptation of process, tools, and Definition of Done.
• Identify organizational impediments surfaced in retrospectives and choose an escalation path.
• Choose how to measure whether improvements are working without turning it into bureaucracy.
• Identify Retrospective anti-patterns (no ownership, repeating issues) and choose corrective actions.

Artifacts, Commitments, and Done (25%)

Product Backlog and Product Goal

• Explain what the Product Backlog is and what it makes transparent.
• Explain what a Product Goal is and how it guides Product Backlog ordering.
• Decide how the Product Backlog evolves over time based on learning.
• Explain what it means for Product Backlog items to be ordered.
• Identify who is accountable for ordering and what inputs can be used.
• Recognize when too many items are 'high priority' and choose a way to restore meaningful ordering.
• Distinguish Product Backlog refinement from Sprint Planning and identify when refinement should occur.
• Decide how to handle unclear or oversized backlog items so they become workable.
• Recognize when a Product Backlog is being used as a project plan and correct the misunderstanding.
• Choose how to represent non-functional requirements in the Product Backlog in a transparent way.

Sprint Backlog and Sprint Goal

• Explain what the Sprint Backlog is and what it makes transparent.
• Explain the Sprint Goal and how it provides flexibility in the Sprint Backlog.
• Identify who owns the Sprint Backlog and who can change it.
• Decide how Developers should adapt the Sprint Backlog as they learn during the Sprint.
• Recognize when the Sprint Backlog is treated as a contract and correct the behavior.
• Choose how to handle new work discovered during the Sprint while preserving focus.
• Identify when the Sprint Goal is missing or vague and choose a correction.
• Explain how the Sprint Goal supports collaboration with the Product Owner.
• Choose actions to keep the Sprint Backlog transparent (board, tasks, progress) without overreporting.
• Recognize when multiple Sprint Goals are being used and choose a Scrum-aligned correction.

Increment and Definition of Done

• Explain what the Increment is and what it must include (usable, valuable, and meeting the Definition of Done).
• Explain the purpose of the Definition of Done and how it supports transparency.
• Identify who creates the Definition of Done and what constraints may apply.
• Distinguish Definition of Done from acceptance criteria and explain how each is used.
• Recognize when work is 'done but not done' and choose an appropriate correction.
• Decide how to handle incomplete work at the end of a Sprint.
• Decide how to handle a weak Definition of Done that causes rework and low quality.
• Choose actions to improve the Definition of Done over time.
• Recognize when integration is delayed and choose a Scrum-aligned approach that reduces integration risk.
• Explain why a Done Increment each Sprint is essential for reliable inspection at Sprint Review.

Artifact Transparency, Ordering, and Adaptation

• Identify transparency problems in Scrum artifacts (stale backlog, hidden defects, unclear goals) and correct them.
• Choose evidence that best indicates progress toward the Sprint Goal.
• Choose evidence that best indicates progress toward the Product Goal.
• Decide when the Product Backlog should be adapted based on inspection results.
• Decide when the Definition of Done should be adapted based on quality issues.
• Recognize when metrics are being used to compare teams and choose a healthier use.
• Choose how to make impediments transparent so they can be addressed.
• Recognize when ordering decisions are being made by committee and choose a Scrum-aligned correction.
• Decide how to handle dependency constraints using backlog ordering and coordination without adding non-Scrum roles.
• Explain how commitments (Product Goal, Sprint Goal, DoD) reinforce artifact usefulness.

Applying Scrum in Practice (10%)

Change, Emergent Work, and Adaptation During the Sprint

• Decide how to respond when a critical new request arrives mid-Sprint.
• Decide how to respond when new information invalidates part of the Sprint plan.
• Choose how to preserve the Sprint Goal while adjusting scope and tasks.
• Decide when to negotiate with the Product Owner about scope changes during the Sprint.
• Decide when a Sprint should be canceled due to a major shift in priorities.
• Recognize when frequent mid-Sprint change indicates a planning or backlog problem and choose a fix.
• Choose how to handle unplanned operational work without hiding it.
• Recognize when external dependencies are breaking the Sprint and choose an action.
• Choose a way to make tradeoffs explicit when capacity is constrained.
• Identify when adding process is reducing agility and choose a simpler Scrum-aligned alternative.

Quality, Technical Debt, and Continuous Improvement

• Explain how quality is addressed in Scrum through the Definition of Done and continuous integration of work.
• Recognize when technical debt is increasing and choose actions that improve sustainability.
• Decide how to handle pressure to skip quality steps.
• Choose how to include quality improvements and refactoring in the Product Backlog transparently.
• Identify when a weak Definition of Done is causing rework and improve it.
• Choose improvement actions from retrospectives that strengthen quality and collaboration.
• Recognize when testing is treated as a separate phase and choose a Scrum-aligned correction.
• Decide how to handle defects discovered after the Sprint in a transparent way.
• Choose how to balance new feature work with quality and maintenance work without losing focus on value.
• Recognize the anti-pattern of 'hardening sprints' and choose an alternative.

Metrics, Forecasting, and Evidence of Progress

• Choose the most appropriate evidence to show whether an Increment is Done.
• Differentiate outcomes (value, learning) from outputs (activity, effort) when discussing progress.
• Use empirical evidence from past Sprints to improve forecasting without treating it as a commitment.
• Recognize when velocity is being misused and choose a more appropriate use.
• Choose metrics that increase transparency of flow and quality without incentivizing gaming.
• Decide what to communicate to stakeholders about progress toward the Product Goal.
• Identify when progress reporting is disconnected from Scrum artifacts and correct it.
• Use the Sprint Goal as the primary progress reference rather than task completion.
• Choose a way to inspect progress during the Sprint and adapt the plan accordingly.
• Recognize when metrics are missing context and choose clarifying information to add.

Multiple Teams and Organizational Considerations (Scrum Guide-Aligned)

• Explain what changes when multiple Scrum Teams work on the same product.
• Identify what must remain consistent across teams (Product Goal, Product Backlog, Definition of Done where applicable).
• Recognize integration risks when multiple teams build one product and choose mitigations that preserve transparency.
• Decide how to handle cross-team dependencies using backlog ordering and collaboration.
• Choose how to keep stakeholders engaged when multiple teams contribute to one Increment.
• Recognize when a separate integration phase is being introduced and choose a more Scrum-aligned approach.
• Identify when organizational policies conflict with empiricism and propose a Scrum-aligned change.
• Choose how a Scrum Master can help the organization remove impediments that affect multiple teams.
• Recognize when governance is demanding predictive commitments and choose how to respond using empirical planning.
• Decide how to share learning and improvements across teams without creating heavy process.