High-yield PSM I review for key rules, traps, decision cues, formulas, and final-week reminders.
Use this for last-mile PSM I review. Pair it with the Syllabus for coverage and Practice to lock in speed.
flowchart TD
A["read the scenario"] --> B{"does the option improve transparency?"}
B -- "no" --> X["usually weak"]
B -- "yes" --> C{"does it preserve self-management and clear accountabilities?"}
C -- "no" --> X
C -- "yes" --> D{"does it inspect and adapt using a real Scrum event, artifact, or increment?"}
D -- "no" --> Y["check for process theater or extra handoffs"]
D -- "yes" --> E["usually stronger"]
PSM I usually rewards the answer that keeps Scrum simple, protects empiricism, and avoids adding managerial control layers that Scrum does not need.
PSM I rewards:
If an option adds approvals, handoffs, status theater, or role confusion, it is often weak even if it sounds organized.
Empiricism pillars: Transparency, Inspection, Adaptation.
Scrum values: Commitment, Focus, Openness, Respect, Courage.
| If the scenario is really about… | Stronger answer pattern | Weaker answer pattern |
|---|---|---|
| hidden work or confusion | increase visibility and make the real state explicit | smooth things over with extra reporting |
| poor progress or missed expectations | inspect a real increment and adapt the plan | defend the original plan longer |
| team hesitation or blame | use openness, respect, and courage to surface the problem | assign fault first |
| pressure to move faster | adapt scope or plan while protecting quality | cut the Definition of Done |
| Accountability | Owns | Usually does not own |
|---|---|---|
| Product Owner | maximizing value, Product Goal, Product Backlog ordering | assigning tasks or acting as delivery manager |
| Scrum Master | Scrum effectiveness, coaching, impediment removal, healthy use of Scrum | command-and-control supervision |
| Developers | Sprint Backlog, plan for the Sprint, creating a Done Increment | waiting for work assignments from outside the team |
Fast rules:
| Event | Real purpose | Stronger exam cue | Common trap |
|---|---|---|---|
| Sprint | stable container for inspection and adaptation | protect the timebox and produce a Done Increment | treating Sprint length as negotiable midstream |
| Sprint Planning | define why this Sprint matters and how work will be done | align on Sprint Goal and realistic plan | overcommitting without capacity thinking |
| Daily Scrum | adapt the plan for the next 24 hours | Developers inspect progress toward the Sprint Goal | status report for outsiders |
| Sprint Review | inspect results with stakeholders and adapt the Product Backlog | discuss value, feedback, and next choices | demo-only theater |
| Retrospective | improve how the Scrum Team works | agree on a concrete improvement | generic venting with no change |
Timeboxes for a one-month Sprint: Sprint Planning 8h, Daily Scrum 15m, Sprint Review 4h, Retrospective 3h.
| Artifact | Commitment | What strong answers usually do |
|---|---|---|
| Product Backlog | Product Goal | clarify value, order for learning and impact, keep one transparent backlog |
| Sprint Backlog | Sprint Goal | adapt the plan while keeping the Sprint Goal in view |
| Increment | Definition of Done | treat quality as shared and non-negotiable |
| Item | What it is | What it is not |
|---|---|---|
| Definition of Done | shared quality bar for the Increment | optional aspiration |
| Acceptance criteria | item-specific conditions for a Product Backlog Item | replacement for a Definition of Done |
| Definition of Ready | optional local aid some teams use | Scrum artifact, event, or commitment |
If work fails the Definition of Done, it is not part of the Increment.
| Situation | Stronger response | Weak response |
|---|---|---|
| scope needs adjustment | re-negotiate scope with the Product Owner while protecting the Sprint Goal | lock the Sprint Backlog as untouchable |
| new learning emerges | adapt the plan and make trade-offs visible | pretend the original plan is still optimal |
| work is late | reduce scope, re-plan, and keep quality intact | extend the Sprint or quietly weaken quality |
| Sprint no longer makes sense | Product Owner may cancel the Sprint | anyone else cancels it informally |
The Sprint Goal gives the team flexibility. The plan can change, but the team should not change it in a way that hides reality.
| Scenario cue | Stronger answer pattern | Weak answer pattern |
|---|---|---|
| requirements are unclear | ask clarifying questions, refine, split work smaller | start building from assumptions |
| stakeholders interrupt Developers every day | coach them toward Sprint Review and clear collaboration paths | add extra status meetings |
| management wants more control | increase transparency with artifacts and events already in Scrum | invent approval gates and sign-offs |
| multiple teams support one product | keep one Product Owner and one Product Backlog | split value ownership across competing backlogs |
| team struggles repeatedly with quality | improve the system, practices, and Definition of Done | rely on late heroics and manual cleanup |
| Term | Exam-useful meaning |
|---|---|
| Empiricism | evidence-driven inspection and adaptation |
| Self-management | the Scrum Team decides who does what, when, and how |
| Transparency | work, quality, and constraints are visible enough for good decisions |
| Increment | usable step toward the Product Goal that meets the Definition of Done |
| Product Goal | long-term objective for the Product Backlog |
| Sprint Goal | single objective that gives the Sprint coherence |
Ready to drill? Use the PSM I practice handoff or go straight to the PSM I practice preview on MasteryExamPrep.