PSM I — Scrum.org Professional Scrum Master I Exam Blueprint
Practical exam blueprint for candidates preparing for the Scrum.org Professional Scrum Master I (PSM I) exam.
How to Use This Exam Blueprint
Use this checklist as a practical study map for the Scrum.org Professional Scrum Master I (PSM I) exam from Scrum.org. The goal is not just to remember Scrum terms. You should be able to apply Scrum rules, accountabilities, events, artifacts, commitments, values, and empirical thinking to short scenarios.
For each topic area, ask:
- Can I explain the concept using Scrum language?
- Can I identify what is mandatory in Scrum versus optional practice?
- Can I choose what the Scrum Master, Product Owner, Developers, or Scrum Team should do next?
- Can I spot anti-patterns such as command-and-control behavior, missing transparency, weak Definition of Done, or skipping inspection and adaptation?
PSM I readiness areas
| Readiness area | What to review | You are ready when you can… |
|---|---|---|
| Scrum purpose and theory | Empiricism, lean thinking, complexity, transparency, inspection, adaptation | Explain why Scrum works through frequent inspection of transparent work and adaptation based on evidence |
| Scrum values | Commitment, Focus, Openness, Respect, Courage | Identify how values support Scrum events, self-management, and difficult conversations |
| Scrum Team | Product Owner, Scrum Master, Developers, one Scrum Team focused on one Product Goal | Distinguish accountabilities without adding traditional project roles |
| Product Owner | Product Goal, Product Backlog, ordering, value, stakeholder interaction | Decide what the Product Owner owns versus what the Developers or Scrum Master own |
| Scrum Master | True leader, Scrum effectiveness, coaching, facilitation, impediment removal | Choose servant-leadership actions instead of command, assignment, or administrative control |
| Developers | Creating usable Increment, Sprint Backlog, plan, quality, Definition of Done | Explain why Developers manage their own work and are accountable for creating a Done Increment |
| Scrum Events | Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective | Know the purpose of each event and what inspection/adaptation happens there |
| Scrum Artifacts | Product Backlog, Sprint Backlog, Increment | Connect each artifact to transparency and its commitment |
| Commitments | Product Goal, Sprint Goal, Definition of Done | Identify which commitment provides focus for which artifact |
| Definition of Done | Quality standard, usable Increment, transparency | Decide whether work is Done, incomplete, releasable, or hidden technical debt |
| Product Backlog management | Refinement, ordering, value, clarity, decomposition | Apply Product Backlog thinking without turning refinement into a mandatory event or phase gate |
| Sprint Planning | Why, What, How; Sprint Goal; selected Product Backlog items; plan | Determine what must be established before the Sprint begins |
| Daily Scrum | Developers inspect progress toward Sprint Goal and adapt plan | Avoid treating it as a status meeting for the Scrum Master |
| Sprint Review | Inspect Increment and adapt Product Backlog with stakeholders | Distinguish review from approval meeting, demo-only session, or sign-off gate |
| Sprint Retrospective | Inspect Scrum Team effectiveness and plan improvements | Identify improvement actions that can be added to the next Sprint Backlog when appropriate |
| Sprint execution | Scope negotiation, Sprint Goal, emergent work, impediments | Decide how to respond when new information appears during a Sprint |
| Scaling basics | Multiple Scrum Teams working on one product | Recognize the need for shared product focus, integrated Increment, and common Definition of Done |
| Agile and Scrum misconceptions | Velocity obsession, project manager role, hardening Sprints, partial Done, skipped events | Spot practices that conflict with Scrum even if they are common in organizations |
Scrum theory and empirical process control
Can you do this?
- Explain why Scrum is designed for complex work where more is learned by doing.
- Define empiricism in practical terms: decisions based on what is observed.
- Connect transparency, inspection, and adaptation to every Scrum event.
- Explain why inspection without transparency can lead to false decisions.
- Explain why adaptation must happen quickly enough to minimize further deviation.
- Identify when a team is using predictive control instead of empirical control.
- Explain how lean thinking relates to reducing waste and focusing on essentials.
Scenario cues
| If the scenario says… | Think about… |
|---|---|
| Progress reports look good, but no usable Increment exists | Transparency problem; inspect real Done work, not activity |
| Management wants detailed long-term certainty for complex work | Empirical planning, frequent inspection, Product Backlog adaptation |
| Problems are known but not discussed | Lack of openness, transparency, courage, or safety |
| Events happen, but no decisions change | Inspection without adaptation |
| The team waits for approval before improving | Weak self-management or misunderstood accountability |
Scrum values readiness
| Scrum value | Practical exam meaning | Common trap |
|---|---|---|
| Commitment | Commitment to goals, quality, teamwork, and professionalism | Assuming commitment means promising fixed scope regardless of learning |
| Focus | Focus on Sprint Goal, Product Goal, and valuable work | Treating every Product Backlog item as equally urgent |
| Openness | Making work, problems, and progress visible | Hiding incomplete work or impediments to avoid conflict |
| Respect | Trusting people as capable professionals | Scrum Master or manager assigning all tasks |
| Courage | Facing hard truths and making necessary changes | Continuing weak practices because “that is how we do it here” |
Can you apply the values?
- Choose a Scrum Master response that encourages transparency instead of blame.
- Identify when the Product Owner needs courage to say no or reorder work.
- Identify when Developers need openness about quality, technical debt, or forecast risk.
- Explain how respect supports self-management.
- Recognize that values are not separate from Scrum mechanics; they make Scrum work.
Scrum Team and accountabilities
Core accountability map
| Accountability | Owns / is accountable for | Does not mean… |
|---|---|---|
| Product Owner | Maximizing product value, Product Goal, Product Backlog management | Writing every Product Backlog item alone or acting as a project manager |
| Scrum Master | Establishing Scrum, helping everyone understand and use Scrum, improving Scrum Team effectiveness | Secretary, task assigner, status collector, team boss, or delivery manager |
| Developers | Creating a usable Increment each Sprint, Sprint Backlog, quality, adapting the plan | Only programmers, or people who wait for assigned tasks |
| Scrum Team | Delivering value through a Done Increment and working toward product goals | Separate sub-teams with handoffs and competing priorities |
Can you do this?
- Distinguish Scrum accountabilities from job titles.
- Explain why there is no separate project manager accountability in Scrum.
- Identify which decisions belong to the Product Owner.
- Identify which decisions belong to the Developers.
- Identify which situations call for Scrum Master coaching or facilitation.
- Explain why the entire Scrum Team is accountable for creating valuable, useful Increments.
- Recognize that Scrum Teams are cross-functional and self-managing.
Product Owner exam blueprint
Product Owner readiness table
| Topic | What to know | Exam-style decision prompt |
|---|---|---|
| Product Goal | Long-term objective for the Scrum Team | If Product Backlog items conflict, how does the Product Goal guide ordering? |
| Product Backlog | Emergent, ordered list of what is needed to improve the product | Who is accountable for ordering and transparency? |
| Value | Product Owner maximizes value | What should be done when stakeholder requests exceed capacity? |
| Stakeholders | Product Owner engages with stakeholders and users | How are stakeholder needs reflected without bypassing Product Backlog ordering? |
| Delegation | Product Owner may delegate work but remains accountable | If analysts write backlog items, who remains accountable? |
| Ordering | Based on value, risk, dependencies, learning, and goals | What should happen when new information changes priorities? |
Can you do this?
- Explain the difference between owning the Product Backlog and doing all Product Backlog work personally.
- Decide when the Product Owner should reorder the Product Backlog.
- Recognize that multiple stakeholders do not mean multiple Product Owners for one Scrum Team.
- Explain why the Product Owner must be empowered to make product decisions.
- Identify how the Product Owner collaborates with Developers during refinement and Sprint Planning.
- Explain how the Product Goal supports focus.
Scrum Master exam blueprint
Scrum Master service areas
| Serves… | By helping with… | Readiness check |
|---|---|---|
| Scrum Team | Self-management, cross-functionality, focus on Done, removing impediments | Can you choose coaching over command? |
| Product Owner | Product Goal, Product Backlog management, stakeholder collaboration, empirical planning | Can you support without taking over product decisions? |
| Organization | Scrum adoption, understanding Scrum, removing organizational impediments | Can you identify when the impediment is outside the team? |
What a Scrum Master should and should not do
| Situation | Better Scrum Master response | Trap answer |
|---|---|---|
| Developers are late on several tasks | Facilitate transparency and help them inspect progress toward Sprint Goal | Reassign tasks personally |
| Product Owner is unavailable | Coach on accountability and impact; help improve collaboration | Make product priority decisions for the Product Owner |
| Daily Scrum becomes a status report | Coach Developers on inspecting progress and adapting their plan | Run the meeting as a manager |
| Organization demands skipped Retrospectives | Explain value of inspection/adaptation and help remove pressure | Cancel events to “save time” |
| Team hides unfinished work | Reinforce Definition of Done and transparency | Count partially done work as complete |
Can you do this?
- Identify the Scrum Master as accountable for Scrum effectiveness.
- Explain “true leader” behavior in practical scenarios.
- Choose facilitation, coaching, teaching, mentoring, or impediment removal appropriately.
- Recognize when the Scrum Master should not make decisions for others.
- Identify organizational impediments versus team-level impediments.
- Explain why the Scrum Master helps the organization understand empirical product development.
Developers exam blueprint
Developers are accountable for
- Creating a plan for the Sprint: the Sprint Backlog.
- Instilling quality by adhering to a Definition of Done.
- Adapting their plan each day toward the Sprint Goal.
- Holding each other accountable as professionals.
- Creating a usable Increment each Sprint.
Scenario checks
| Scenario | What to decide |
|---|---|
| Developers discover the selected work is larger than expected | Collaborate with the Product Owner; protect the Sprint Goal; adapt the Sprint Backlog |
| A manager wants to assign tasks directly | Developers self-manage the work |
| Testing is planned for a later phase | Quality and Done are at risk; Done Increment is expected each Sprint |
| One specialist is the bottleneck | Cross-functionality, collaboration, and skill sharing may be needed |
| Developers want to skip the Daily Scrum | They still need daily inspection and adaptation of the plan |
Scrum events checklist
Sprint
| Topic | Readiness check |
|---|---|
| Sprint as container | Know that other Scrum events happen within the Sprint |
| Fixed length | Understand why consistency supports rhythm and learning |
| Sprint Goal | The single objective that provides focus |
| No changes that endanger the Sprint Goal | Learn how scope can be clarified or renegotiated without abandoning the goal |
| Quality does not decrease | Never solve schedule pressure by lowering Definition of Done |
| Cancellation | Understand that cancellation is exceptional and tied to the Sprint Goal becoming obsolete |
Sprint can-you-do-this list
- Explain what starts a Sprint.
- Explain what ends a Sprint.
- Identify what may change during a Sprint.
- Identify what should not change during a Sprint.
- Explain the difference between changing scope and changing the Sprint Goal.
- Recognize that undone work returns to the Product Backlog or is otherwise made transparent.
Sprint Planning
Sprint Planning focus
| Planning question | Practical meaning |
|---|---|
| Why is this Sprint valuable? | Establish the Sprint Goal |
| What can be Done this Sprint? | Select Product Backlog items through collaboration |
| How will the chosen work get done? | Developers plan the work enough to begin |
Can you do this?
- Identify required participation: the Scrum Team collaborates.
- Explain how the Product Goal and Product Backlog inform planning.
- Explain that Developers forecast what they can complete.
- Recognize that Sprint Planning is not a contract for fixed scope.
- Distinguish Sprint Goal from a list of Product Backlog items.
- Explain how the Sprint Backlog is created.
Daily Scrum
| What it is | What it is not |
|---|---|
| Event for Developers | Status meeting for the Scrum Master |
| Inspection of progress toward Sprint Goal | Detailed problem-solving session for every issue |
| Opportunity to adapt the Sprint Backlog | Reporting ceremony for management |
| Focused on actionable planning | A required speaking order or script |
Can you do this?
- Explain who the Daily Scrum is for.
- Identify that Developers may meet at other times for detailed discussions.
- Choose answers that adapt the plan toward the Sprint Goal.
- Avoid answers that make the Scrum Master the central reporter.
- Recognize that the Product Owner or Scrum Master may participate if they are actively working as Developers.
Sprint Review
Sprint Review readiness
| Review topic | What to know |
|---|---|
| Purpose | Inspect outcome of the Sprint and determine future adaptations |
| Participants | Scrum Team and key stakeholders collaborate |
| Increment | The Done Increment is central evidence for inspection |
| Product Backlog | May be adapted based on feedback and learning |
| Not a phase gate | It is not merely approval, sign-off, or a demo script |
Can you do this?
- Explain why the Sprint Review is more than a demonstration.
- Identify how stakeholder feedback can influence Product Backlog ordering.
- Recognize that incomplete work should not be presented as Done.
- Explain how market, customer, budget, and capability changes may be discussed without turning the Review into a status meeting.
- Choose actions that increase transparency about the product.
Sprint Retrospective
| Topic | Readiness check |
|---|---|
| Purpose | Inspect the Scrum Team’s effectiveness |
| Scope | People, interactions, processes, tools, Definition of Done, quality, practices |
| Outcome | Plan improvements |
| Timing | Occurs before the next Sprint Planning |
| Anti-pattern | Skipping it because the team is busy |
Can you do this?
- Identify the Retrospective as the event for improving how the Scrum Team works.
- Distinguish Sprint Review product inspection from Retrospective process/team inspection.
- Choose improvement actions that can be made visible and acted on.
- Recognize when Definition of Done improvements should be discussed.
- Explain why repeated unresolved impediments should be made transparent.
Scrum artifacts and commitments
Artifact map
| Artifact | Purpose | Commitment | Key readiness point |
|---|---|---|---|
| Product Backlog | Ordered work needed to improve the product | Product Goal | Provides transparency about future product work |
| Sprint Backlog | Sprint Goal, selected Product Backlog items, and plan | Sprint Goal | Owned and adapted by Developers during the Sprint |
| Increment | Sum of completed work that meets Definition of Done | Definition of Done | Must be usable and integrated with previous Increments |
Can you do this?
- Match each artifact to its commitment.
- Explain how each commitment improves transparency and focus.
- Identify which artifact should be updated in a scenario.
- Explain why artifacts are not just documents; they create transparency.
- Recognize that an Increment exists only when work meets the Definition of Done.
Definition of Done and quality
Definition of Done decision table
| Scenario | Ready response |
|---|---|
| Feature is coded but not tested | Not Done if testing is part of the Definition of Done |
| Work meets team-level criteria but not organizational criteria | Definition of Done must meet applicable organizational standards |
| Several teams work on one product | They need a shared understanding of Done for integrated Increments |
| Product Owner wants to accept partial work as Done | Done is determined by the Definition of Done, not preference |
| Team wants a hardening Sprint | Inspect why Done is not being achieved each Sprint |
Can you do this?
- Explain why Definition of Done is essential for transparency.
- Identify the risk of counting undone work as complete.
- Distinguish acceptance criteria from Definition of Done.
- Explain why quality should not decrease during a Sprint.
- Recognize that Done work is usable, even if the Product Owner chooses not to release it immediately.
Product Backlog and refinement readiness
Product Backlog checklist
- Product Backlog is ordered.
- Product Backlog is emergent.
- Product Backlog items can vary in size and detail.
- Higher-ordered items are usually clearer than lower-ordered items.
- Product Backlog management remains the Product Owner’s accountability.
- Refinement is ongoing work, not a separate mandatory Scrum event.
- Developers contribute sizing, technical insight, dependencies, and feasibility information.
- Product Backlog ordering can reflect value, risk, learning, dependencies, and stakeholder needs.
Common Product Backlog traps
| Trap | Why it is weak |
|---|---|
| Treating the Product Backlog as a fixed requirements document | Scrum expects learning and emergence |
| Letting stakeholders directly assign work to Developers | Product Owner is accountable for ordering and value |
| Treating refinement as sign-off | Refinement improves understanding; it is not a phase gate |
| Splitting backlog by component teams | Risks reducing product focus and integrated value |
| Selecting work without a Sprint Goal | Reduces focus and makes adaptation harder |
Increment, release, and value checks
Can you do this?
- Explain that an Increment is created when Product Backlog items meet the Definition of Done.
- Distinguish “Done” from “released.”
- Explain why the Product Owner may decide when to release value.
- Recognize that the Sprint Review is not the only possible time to release.
- Identify that multiple Increments may be created during a Sprint if they meet Done.
- Explain why an Increment should be usable.
Scenario cues
| If the question says… | Look for… |
|---|---|
| “The work is almost complete” | Not Done unless it meets the Definition of Done |
| “The Product Owner accepts it anyway” | Product Owner acceptance does not override Done |
| “The team will integrate later” | Integration risk; Increment transparency problem |
| “The customer does not want it released yet” | Done and releasable can exist without immediate release |
| “Testing will happen next Sprint” | Current Sprint Increment may not be Done |
Decision-point checklist: what should happen next?
| Scenario | Strong Scrum answer usually points toward… |
|---|---|
| Stakeholder wants to add urgent work mid-Sprint | Product Owner and Developers discuss impact; Sprint Goal remains central |
| Sprint Goal becomes obsolete | Product Owner may cancel the Sprint |
| Developers cannot complete all selected items | Make it transparent; collaborate with Product Owner; focus on Sprint Goal |
| Daily Scrum is ineffective | Scrum Master coaches; Developers adapt format to meet purpose |
| Product Backlog is unclear before Sprint Planning | Product Owner and Developers refine enough to support planning |
| Done criteria are inconsistent | Improve Definition of Done transparency and shared understanding |
| Quality is declining | Inspect in Retrospective; do not lower quality to hit scope |
| Scrum events are skipped | Scrum Master helps organization understand consequences |
| Product Owner is overruled by a committee | Product ownership empowerment problem |
| Developers are assigned tasks by a lead | Self-management problem |
Scrum artifact update guide
| New information appears… | Artifact or commitment likely affected |
|---|---|
| Long-term product objective changes | Product Goal and Product Backlog |
| Stakeholder feedback changes priority | Product Backlog ordering |
| Sprint work plan changes but goal remains | Sprint Backlog |
| Sprint objective is no longer valid | Sprint Goal; possible Sprint cancellation |
| Quality criteria improve | Definition of Done |
| Completed work meets Done | Increment |
| Retrospective improvement is chosen for next Sprint | Sprint Backlog may include improvement work |
| Product Backlog item is better understood | Product Backlog refinement |
Scrum Master scenario judgment
Choose the answer that preserves Scrum
| Question pattern | Prefer answers that… | Avoid answers that… |
|---|---|---|
| “The team is not following Scrum” | Teach, coach, facilitate, make impacts transparent | Punish, command, or secretly fix |
| “Management wants reports” | Use transparent artifacts and outcomes | Create parallel bureaucracy that hides reality |
| “Developers are blocked” | Help remove impediments and improve self-management | Personally assign all work |
| “Product Owner is unavailable” | Coach and address accountability gaps | Let Developers choose product priorities alone |
| “Events feel wasteful” | Reconnect events to inspection and adaptation | Cancel events without solving the underlying issue |
| “Quality is poor” | Improve Done, engineering practices, and transparency | Add a late testing phase as normal Scrum |
Agile, predictive, and hybrid confusion points
PSM I questions often reward clear Scrum thinking. Be careful when a scenario mixes Scrum terms with traditional project-management habits.
| Mixed-practice cue | Scrum interpretation |
|---|---|
| Project manager assigns tasks | Not Scrum accountability; Developers self-manage |
| Phase-gate approval of Sprint output | Sprint Review is for inspection and adaptation, not just sign-off |
| Fixed scope commitment for the Sprint | Developers forecast; Sprint Goal gives focus |
| Separate test phase after development | Challenges the idea of a Done Increment each Sprint |
| Change control board approves all backlog changes | Product Owner accountability may be undermined |
| Status meeting Daily Scrum | Misunderstands the Developers’ inspection/adaptation event |
| Retrospective only after release | Misses Sprint-level continuous improvement |
| Velocity used as a performance target | Can distort transparency and behavior |
Scaling and multiple-team readiness
Can you do this?
- Explain that multiple Scrum Teams can work on the same product.
- Recognize the need for one Product Backlog for one product.
- Explain why integrated Done work matters when several teams contribute.
- Identify problems caused by component-only teams, late integration, or separate Done standards.
- Recognize that adding teams increases coordination needs but does not remove Scrum accountabilities.
- Explain why a common Definition of Done supports transparency across teams.
Scenario cues
| Scenario | Watch for |
|---|---|
| Each team has its own Product Owner for the same product | Product ownership and ordering confusion |
| Teams integrate only before release | Increment and Definition of Done risk |
| Teams use different Done standards | Transparency problem |
| Dependencies block several teams | Need to inspect product structure, team design, and backlog ordering |
| Teams optimize local component output | Product value and integrated Increment may suffer |
Common weak areas and traps
| Weak area | What to fix before exam day |
|---|---|
| Memorizing event names only | Know the purpose, participants, artifact inspected, and adaptation produced |
| Confusing Product Owner with project sponsor | Product Owner is accountable for product value and Product Backlog management |
| Treating Scrum Master as manager | Scrum Master leads through service, coaching, facilitation, and Scrum expertise |
| Thinking Developers are only coders | Developers are everyone committed to creating the Increment |
| Forgetting commitments | Product Backlog has Product Goal; Sprint Backlog has Sprint Goal; Increment has Definition of Done |
| Confusing Sprint Review and Retrospective | Review inspects product outcome; Retrospective inspects team/process effectiveness |
| Accepting partial Done | Undone work is not part of the Increment |
| Assuming Sprint scope is fixed | Sprint Goal is protected; scope may be clarified or renegotiated |
| Making refinement mandatory as an event | Refinement is important ongoing work, not one of the formal Scrum events |
| Overusing velocity | Scrum focuses on value, transparency, Done work, and goals, not metric gaming |
High-value “Can you do this?” checklist
Before sitting for PSM I, you should be able to answer yes to each item.
Scrum framework
- I can name the Scrum accountabilities, events, artifacts, and commitments.
- I can explain how each event enables inspection and adaptation.
- I can match each artifact to its commitment.
- I can identify when Scrum is being changed in a way that reduces transparency.
- I can distinguish Scrum rules from optional complementary practices.
Accountability decisions
- I know when the Product Owner decides ordering and value.
- I know when Developers decide how to do the work.
- I know when the Scrum Master should coach, teach, facilitate, or remove impediments.
- I can avoid answers where the Scrum Master or manager assigns work.
- I can identify when an organization is undermining Product Owner accountability.
Event decisions
- I can identify the purpose of Sprint Planning.
- I can identify what the Daily Scrum adapts.
- I can identify what the Sprint Review inspects.
- I can identify what the Sprint Retrospective improves.
- I can explain what should happen if an event is skipped, misused, or treated as a status ceremony.
Artifact decisions
- I can tell whether the Product Backlog, Sprint Backlog, or Increment is affected by a scenario.
- I can explain how Product Backlog refinement supports readiness without being a mandatory event.
- I can explain why the Sprint Backlog is adapted by Developers.
- I can identify when an Increment is not transparent.
- I can explain why Definition of Done is a quality and transparency standard.
Final-week review checklist
5 to 7 days out
- Re-read the Scrum Guide carefully and slowly.
- Build a one-page map of accountabilities, events, artifacts, and commitments.
- Review every missed practice question by identifying the Scrum principle behind the answer.
- Make a trap list: status meeting, project manager, partial Done, skipped events, fixed Sprint scope, weak Product Owner.
- Practice explaining each Scrum event in one sentence.
2 to 4 days out
- Drill scenario questions where more than one answer sounds reasonable.
- Review Product Owner versus Scrum Master versus Developers decision rights.
- Recheck Definition of Done, Increment, release, and unfinished work scenarios.
- Compare Sprint Review and Sprint Retrospective until you cannot confuse them.
- Practice identifying which artifact or commitment changes in a scenario.
Final 24 hours
- Do a focused pass on Scrum values and empiricism.
- Review artifact-commitment pairs.
- Review common anti-patterns.
- Avoid cramming unrelated agile frameworks unless they clarify Scrum.
- Get comfortable reading questions literally and choosing the answer most consistent with Scrum.
Quick readiness self-test
Use these prompts without looking at notes:
- What is the difference between the Sprint Goal and the selected Product Backlog items?
- Who is accountable for Product Backlog ordering?
- Who owns the Sprint Backlog?
- What makes an Increment transparent?
- When is work considered Done?
- What is inspected at the Sprint Review?
- What is inspected at the Sprint Retrospective?
- What should the Scrum Master do when the Daily Scrum becomes a reporting meeting?
- What should happen when new urgent work appears during a Sprint?
- Why is a hardening Sprint usually a warning sign?
- How do Scrum values support empiricism?
- What changes when multiple Scrum Teams work on one product?
If any answer feels vague, return to that topic area and practice with scenario-based questions until the Scrum response is clear.
Practical next step
After reviewing this exam blueprint, take a mixed set of PSM I practice questions and label each miss by root cause: Scrum theory, accountability, event purpose, artifact/commitment, Definition of Done, or scenario judgment. Then revisit only the weak areas and retest with fresh questions.