PSM I Syllabus — Learning Objectives by Domain

Blueprint-aligned PSM I learning objectives organized by domain with quick links to targeted practice.

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%)

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.