PSM I — Scrum.org Professional Scrum Master I Cheat Sheet
Last revised: September 16, 2026
Compact Scrum.org PSM I Cheat sheet covering Scrum accountabilities, events, artifacts, commitments, empiricism, Scrum Master decisions, and common exam traps.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context
Use this as a final-pass review after reading the Scrum Guide carefully.
This page is PM Mastery review support. It is not affiliated with Scrum.org. For final authority on Scrum definitions, use the current Scrum Guide and Scrum.org exam information.
Scrum in One Page
Area
PSM I exam anchor
Scrum purpose
A lightweight framework for generating value through adaptive solutions for complex problems.
Foundation
Empiricism and lean thinking.
Empirical pillars
Transparency, inspection, adaptation.
Scrum values
Commitment, Focus, Openness, Respect, Courage.
Scrum Team
One Product Owner, one Scrum Master, and Developers.
Team structure
Cross-functional, self-managing, no sub-teams or hierarchies within the Scrum Team.
Outcome each Sprint
A valuable, useful Increment that meets the Definition of Done.
Each event has a purpose, timebox, and inspection/adaptation target.
Artifacts
Product Backlog, Sprint Backlog, Increment.
Artifacts create transparency.
Commitments
Product Goal, Sprint Goal, Definition of Done.
Each commitment improves transparency for its artifact.
Value
Every Sprint aims to create a valuable, useful Increment.
Work that is not Done is not part of the Increment.
Change
Scrum welcomes learning while protecting the Sprint Goal and quality.
Scope can be clarified or renegotiated; quality does not decrease.
Empiricism, Lean Thinking, and the Scrum Values
Empirical Pillars
Pillar
Meaning in Scrum
Exam trap
Transparency
Work, progress, artifacts, and standards are visible and understood.
A board, chart, or backlog is not transparent if people interpret it differently or it hides reality.
Inspection
Scrum Team and stakeholders frequently inspect artifacts and progress toward goals.
Inspection without adaptation is not enough.
Adaptation
Adjust process, backlog, plan, or approach when deviations are found.
Adaptation should happen as soon as possible, not only at the end of the Sprint.
Notes and examples
Scrum Values
Value
Practical meaning
Common PSM I angle
Commitment
Commit to goals and support each other.
Commitment is to the Sprint Goal and team success, not to a fixed scope contract.
Focus
Focus on Sprint work and goals.
Mid-Sprint interruptions that threaten the Sprint Goal should be managed visibly.
Openness
Be open about work, challenges, and progress.
Hiding defects, delays, or uncertainty undermines empiricism.
Respect
Respect people as capable and independent.
Scrum Master should coach, not command.
Courage
Do the right thing and work on tough problems.
Raising impediments and challenging poor practices is expected.
Empirical Scrum
Scrum is not a predictive process in which all details are known upfront. It is empirical: decisions are made based on observation, evidence, and learning.
Pillar
Meaning
Candidate trap
Transparency
Important aspects of process and work are visible and understood.
If information is hidden, inspection and adaptation become unreliable.
Inspection
Scrum users frequently inspect artifacts and progress toward goals.
Inspection is not micromanagement or late-stage auditing.
Adaptation
If results deviate or new learning appears, adjust quickly.
Adaptation should happen as soon as possible, not only at Sprint end.
Scrum values
Value
What it looks like in exam scenarios
Commitment
The Scrum Team commits to goals, quality, professionalism, and mutual accountability.
Focus
The team focuses on Sprint work and the Sprint Goal.
Openness
Work, problems, progress, and learning are made visible.
Respect
People are capable, independent professionals.
Courage
The team raises impediments, gives honest feedback, and makes necessary changes.
Common answer pattern: when a question describes hidden problems, unclear progress, or unspoken conflict, the best Scrum answer usually increases transparency and supports inspection/adaptation.
Scrum Accountabilities
Scrum uses three accountabilities, all within one Scrum Team.
“Almost done” work that does not meet DoD is not part of the Increment.
Scrum Team accountabilities
The Scrum Team is a small, cohesive unit of professionals focused on one objective at a time: the Product Goal. It is cross-functional and self-managing.
Accountability
Accountable for
Key decisions
Common traps
Product Owner
Maximizing product value and managing the Product Backlog.
Treating the Product Owner as a committee, proxy, secretary, or requirements writer only.
Scrum Master
Establishing Scrum as defined and helping everyone understand Scrum theory and practice.
How to coach, facilitate, remove impediments, and improve Scrum effectiveness.
Making the Scrum Master a project manager, task assigner, team boss, or status collector.
Developers
Creating any aspect of a usable Increment each Sprint.
How to do the work, how much to select, estimates, daily plan, technical approach.
Having managers assign tasks, separating testers from Developers, or outsourcing quality to a later phase.
Scrum Team essentials
Concept
Correct understanding
Cross-functional
The Scrum Team has all skills needed to create value each Sprint.
Self-managing
The Scrum Team decides who does what, when, and how.
Size
Scrum Teams are typically 10 or fewer people. If too large, consider reorganizing into multiple cohesive Scrum Teams.
No sub-teams
Scrum does not define separate testing, architecture, analysis, or operations sub-teams inside the Scrum Team.
One product
Multiple Scrum Teams working on the same product share the same Product Goal, Product Backlog, and Product Owner.
Product Owner Cheat Sheet
The Product Owner is one person, not a committee. Stakeholders may influence decisions, but the Product Owner remains accountable.
Product Owner responsibility
What to remember
Develop and communicate the Product Goal
The Product Goal describes a future state of the product and gives the Scrum Team a target.
Create and communicate Product Backlog items
The Product Backlog must be understandable enough to support selection and planning.
Order the Product Backlog
Ordering reflects value, risk, dependencies, learning, and other product considerations.
Ensure Product Backlog transparency
The Product Backlog should be visible, understood, and clear enough for decision-making.
Delegate work if needed
The Product Owner may delegate, but remains accountable.
Product Owner traps
Wrong: Stakeholders vote to determine Product Backlog order.
Better: The Product Owner is accountable for ordering, while considering stakeholder input.
Wrong: A committee serves as the Product Owner.
Better: The Product Owner is one person.
Wrong: The Scrum Master prioritizes the Product Backlog because they facilitate Scrum.
Better: Product Backlog ordering is Product Owner accountability.
Wrong: Developers must accept any Product Backlog item selected by the Product Owner.
Better: Developers select how much work they believe they can complete during Sprint Planning.
Developers Cheat Sheet
Developers are the people in the Scrum Team committed to creating any aspect of a usable Increment each Sprint. “Developer” is an accountability in Scrum, not only a software job title.
Developers are accountable for
Exam meaning
Creating the Sprint Backlog plan
Developers determine how selected work will be done.
Instilling quality by adhering to the Definition of Done
Quality is built in, not inspected in later as a separate phase.
Adapting the plan each day toward the Sprint Goal
Daily adaptation belongs to Developers.
Holding each other accountable as professionals
Self-management includes peer accountability.
Estimating Product Backlog items
The Product Owner may influence, but Developers estimate.
Developer traps
The Scrum Master does not assign tasks.
The Product Owner does not decide how much work Developers must take into a Sprint.
Managers outside the Scrum Team do not direct daily work.
A specialist can contribute specialist skills, but all Developers share accountability for the Increment.
Testing, integration, documentation, and other quality work must be part of creating a Done Increment, not deferred to a “hardening Sprint.”
Scrum Events
All events are opportunities to inspect and adapt. They exist to create regularity and reduce the need for extra meetings.
Event
Timebox
Participants
Purpose
Key output / focus
Sprint
One month or less
Whole Scrum Team
Container for all Scrum events and work to create value.
Increment; progress toward Product Goal.
Sprint Planning
Max 8 hours for a one-month Sprint
Whole Scrum Team
Initiate the Sprint by planning why, what, and how.
People, interactions, processes, tools, Definition of Done.
Adapts
Product Backlog and future product decisions.
Team practices and improvement actions.
Common trap
Treating it as a formal demo or acceptance gate.
Skipping it when no major problems occurred.
Artifacts and Commitments
Each Scrum artifact has a commitment that improves transparency and focus.
Artifact
Represents
Commitment
Commitment purpose
Product Backlog
Emergent, ordered list of what is needed to improve the product.
Product Goal
Describes a future state of the product that guides planning.
Sprint Backlog
Sprint Goal, selected Product Backlog Items, and plan for delivering them.
Sprint Goal
Gives Developers flexibility in what work is needed to achieve the objective.
Increment
Concrete stepping stone toward Product Goal; sum of all completed work that meets DoD.
Definition of Done
Creates shared understanding of what “Done” means.
Notes and examples
Product Backlog
Rule
Exam implication
Product Backlog is never complete.
It evolves as product, market, users, and learning evolve.
Product Backlog is ordered.
Ordering is broader than priority; it can reflect value, risk, dependencies, learning, or other factors.
Product Backlog refinement is ongoing.
Refinement is not a formal Scrum event and has no required timebox in current Scrum.
Product Backlog Items vary in size.
Items selected for Sprint Planning are usually sufficiently refined to be understood.
Product Goal guides the Product Backlog.
Multiple product directions without a clear Product Goal reduce transparency.
Sprint Backlog
Contains
Notes
Sprint Goal
The single objective for the Sprint.
Selected Product Backlog Items
The work forecast for the Sprint.
Plan
Developers’ evolving plan for delivering the Increment.
Rule
Exam implication
Owned by Developers.
Others do not assign or rewrite the plan for Developers.
Emergent
More work may be discovered as the Sprint progresses.
Adapted during Sprint
Developers update it as they learn.
Scope can be clarified and renegotiated
Product Owner and Developers collaborate if selected work changes.
Sprint Goal should remain intact
Changes that endanger the Sprint Goal need inspection and adaptation.
Increment and Definition of Done
Concept
Correct interpretation
Increment
Work that is usable and meets the Definition of Done.
Multiple Increments
Multiple Increments may be created within a Sprint.
Release
An Increment may be released before the end of the Sprint; Scrum does not require waiting for Sprint Review.
DoD
Formal description of the state of the Increment when it meets required quality measures.
If work does not meet DoD
It is not part of the Increment.
If organization has standards
They are part of the minimum Definition of Done.
If multiple Scrum Teams work on one product
They share the same Definition of Done for the integrated Increment.
Artifacts and commitments
Scrum artifacts maximize transparency. Each artifact has a commitment that improves focus and measurability.
Artifact
Represents
Commitment
Commitment purpose
Product Backlog
Emergent, ordered list of what is needed to improve the product.
Product Goal
Provides a long-term objective for the Scrum Team.
Sprint Backlog
Sprint Goal, selected Product Backlog items, and plan.
Sprint Goal
Explains why the Sprint is valuable and provides focus.
Increment
A concrete stepping stone toward the Product Goal.
Definition of Done
Makes quality and completeness transparent.
Product Backlog and Product Goal
The Product Backlog is never “complete” in a predictive sense. It evolves as the product, market, users, and learning evolve.
Concept
Review point
Product Backlog item detail
Items that are likely to be selected soon are usually refined into more detail.
Ordering
The Product Owner is accountable for ordering.
Estimates
Developers are responsible for estimates.
Refinement
Ongoing activity to add detail, order, and size; not a formal Scrum event.
Product Goal
The long-term objective in the Product Backlog. The Scrum Team must fulfill or abandon one Product Goal before taking on the next.
Trap: Scrum does not require user stories as the Product Backlog item format. User stories are common, but Product Backlog items can take other forms.
Sprint Backlog and Sprint Goal
The Sprint Backlog belongs to the Developers. It is updated throughout the Sprint as more is learned.
Item
Correct understanding
Sprint Goal
A single objective for the Sprint, not just a list of tasks.
Selected Product Backlog items
Forecast of work Developers believe they can complete.
Plan
Emergent plan created and adapted by Developers.
Change during Sprint
Developers can adapt the Sprint Backlog as long as the Sprint Goal is not endangered and quality does not decrease.
Trap: A Sprint Goal gives flexibility. If one selected item becomes unnecessary, the Scrum Team may adjust scope while still pursuing the Sprint Goal.
Increment and Definition of Done
An Increment is usable and provides value. Multiple Increments may be created during a Sprint. An Increment is created when a Product Backlog item meets the Definition of Done.
Definition of Done rule
Exam meaning
Work not meeting the Definition of Done is not part of the Increment.
It cannot be counted as Done.
The Increment must be usable.
“Almost done” is not Done.
Release is a business decision.
Scrum does not require waiting until Sprint Review to release.
If the organization has standards, they are the minimum Definition of Done.
The Scrum Team can add stricter criteria.
Multiple Scrum Teams on one product share a Definition of Done.
Integrated product quality must be transparent.
Definition of Done traps
Lowering the Definition of Done to meet a deadline is not Scrum.
Separate testing after the Sprint hides undone work.
A Definition of Ready may be used by some teams, but Scrum does not require it.
Acceptance criteria and Definition of Done are not the same thing. Acceptance criteria may describe item-specific expectations; the Definition of Done describes the quality standard for Increment completeness.
Sprint Rules and Change Decisions
What Can Change During a Sprint?
Item
Can it change?
PSM I reasoning
Sprint length
No, not during the Sprint.
Sprint cadence provides regularity and limits risk.
Sprint Goal
Avoid changing.
It is the commitment for the Sprint Backlog. If obsolete, Product Owner may cancel Sprint.
Selected Product Backlog Items
Yes, if needed.
Product Owner and Developers may renegotiate scope while preserving Sprint Goal.
Sprint Backlog plan
Yes.
Developers adapt the plan as they learn.
Product Backlog
Yes.
Product Backlog evolves continuously, but changes do not automatically disrupt Sprint work.
Definition of Done
Can improve, but not to hide undone work.
Changes should increase transparency and quality, not lower standards midstream.
Team composition
Avoid changes during Sprint when possible.
Changes can reduce focus and self-management; Scrum does not define a formal freeze rule.
Notes and examples
Sprint Cancellation
Question
Answer
Who can cancel?
Product Owner.
When?
If the Sprint Goal becomes obsolete.
Is cancellation common?
No; because Sprints are short.
What happens to completed work?
Done work is reviewed as potentially releasable/useful.
What happens to incomplete work?
Re-estimated or returned to Product Backlog as appropriate.
Trap
Scrum Master, stakeholders, or management do not cancel the Sprint by authority.
“What Should the Scrum Master Do?” Decision Table
Situation
Best Scrum Master stance
Avoid
Developers are waiting for task assignments.
Coach self-management; help Developers create and adapt their own plan.
Assigning tasks to individuals.
Product Owner is unavailable.
Coach Product Owner on accountability and help organization address availability impediment.
Acting as proxy Product Owner long-term.
Stakeholders want to change Sprint scope.
Help Product Owner and Developers collaborate; protect Sprint Goal transparency.
Blocking all change automatically or accepting all change silently.
Daily Scrum becomes status reporting.
Coach Developers on purpose: inspect progress and adapt plan.
Turning it into a Scrum Master-led reporting meeting.
Management asks for individual productivity metrics.
Coach on team accountability, empiricism, and useful outcome-based transparency.
Ranking Developers or using velocity as a performance target.
Team wants to skip Retrospective.
Reinforce that Retrospective is required and improves adaptation.
Allowing events to disappear because people are busy.
Work is repeatedly not Done.
Make the problem transparent; coach on DoD, quality, refinement, and realistic planning.
Extending the Sprint to finish work.
Scrum events exceed timeboxes.
Facilitate better preparation and focus; teach timebox purpose.
Improve DoD and engineering practices so each Sprint produces usable work.
“Separate QA team signs off later.”
Scrum Team is accountable for Done Increment; external standards may exist but do not remove team accountability.
When stakeholders are unhappy
Best Scrum-oriented responses usually:
Increase collaboration with the Product Owner and stakeholders.
Use Sprint Review to inspect outcomes and adapt the Product Backlog.
Improve Product Backlog transparency.
Avoid bypassing the Product Owner or disrupting Developers mid-Sprint.
When Developers are not finishing work
Look for answers that:
Inspect why work is not reaching Done.
Strengthen refinement, Sprint Planning, slicing, and technical practices.
Keep the Definition of Done intact.
Encourage Developers to select a realistic amount of work.
Avoid carrying large amounts of undone work as if it were complete.
When management wants more control
Prefer answers that:
Make progress, impediments, and Increment quality transparent.
Teach Scrum accountabilities.
Preserve Developer self-management.
Keep the Product Owner accountable for product value.
Avoid adding command-and-control roles inside the Scrum Team.
When the Sprint Goal is at risk
Good responses may include:
Developers adapt the Sprint Backlog.
The Scrum Team collaborates with the Product Owner.
Scope is clarified or renegotiated.
Impediments are made transparent.
Quality does not decrease.
Poor responses include hiding the issue, extending the Sprint, cancelling automatically, or declaring partially done work as Done.
Scrum Master Anti-Patterns
Anti-pattern
Why it is wrong for PSM I
Assigns tasks to Developers
Violates self-management.
Acts as team secretary only
Scrum Master is accountable for Scrum effectiveness, not just administration.
Owns the Daily Scrum
Daily Scrum is for Developers.
Forces the team to use one specific practice
Scrum is a framework; practices should serve empiricism and value.
Protects the team by hiding information
Reduces transparency.
Solves every problem personally
Prevents team ownership and growth.
Becomes proxy Product Owner
Confuses accountabilities.
Treats Scrum events as optional
Events are prescribed by Scrum to enable inspection and adaptation.
Measures success by compliance only
Scrum aims to deliver value, not just follow ceremonies.
Scrum Artifacts: Transparency Checklist
Artifact
Transparent when…
Warning sign
Product Backlog
Ordered, visible, understood, aligned to Product Goal.
Stakeholders and Developers cannot tell what matters next or why.
Sprint Backlog
Shows Sprint Goal, selected work, and current plan.
Only Scrum Master updates it or it hides discovered work.
Increment
Clearly meets DoD and is usable.
“Done” means different things to different people.
Definition of Done
Shared, explicit, and applied consistently.
Work is accepted with known gaps outside DoD.
Product Goal
Clear enough to guide decisions.
Product Backlog is a collection of unrelated requests.
Sprint Goal
Provides focus and flexibility.
Sprint success equals completing a disconnected task list.
Scrum Events: Required, Timeboxed, Purpose-Driven
Event
If skipped or weakened
Likely consequence
Sprint Planning
No shared goal or plan.
Confusion, weak focus, poor forecast.
Daily Scrum
Less frequent adaptation.
Problems found late; Sprint Goal at risk.
Sprint Review
Less stakeholder feedback.
Product Backlog becomes less empirical.
Sprint Retrospective
Less process improvement.
Same impediments repeat.
Sprint
No container for cadence and inspection.
Work becomes less predictable and less empirical.
“Scrum Says” vs “Common Practice” Traps
Common practice
Scrum position for PSM I
User stories are mandatory.
Not mandatory. Product Backlog Items can take various forms.
Story points are mandatory.
Not mandatory.
Velocity is required.
Not required.
Burn-down chart is a Scrum artifact.
Not a Scrum artifact.
Sprint 0 is part of Scrum.
Not defined in Scrum.
Hardening Sprint is part of Scrum.
Not defined; conflicts with Done Increment each Sprint if used to finish quality later.
Release Sprint is required.
Not defined.
Product Owner must write all PBIs.
Product Owner is accountable for backlog management but may delegate.
Scrum Master must attend every Daily Scrum.
Scrum Master ensures the event occurs and is effective, but Daily Scrum is for Developers.
Sprint Review is a demo.
It is a collaborative inspection and adaptation session.
Retrospective is optional.
It is a required Scrum event.
Scrum Team contains project manager role.
Scrum defines Product Owner, Scrum Master, and Developers.
Testers are not Developers.
In Scrum, anyone committed to creating the Increment is a Developer, regardless of specialty.
Scaling and Multiple-Team Basics
PSM I is mainly focused on core Scrum, but questions may test how core Scrum applies when multiple teams work on one product.
Scenario
Scrum-consistent answer
Multiple Scrum Teams work on one product
They share one Product Goal, one Product Backlog, and one Product Owner.
Multiple teams create one Increment
Work must integrate into a single Increment that meets the Definition of Done.
Different teams use different DoDs
If they work on the same product, they need a shared Definition of Done sufficient for the integrated Increment.
Dependencies between teams
Make dependencies transparent; teams collaborate and adapt.
Component teams create handoffs
Prefer cross-functional teams able to deliver usable product value.
High-Yield Definitions
Term
Compact definition
Scrum
Lightweight framework for generating value through adaptive solutions to complex problems.
Empiricism
Knowledge comes from experience and decisions based on observation.
Lean thinking
Reduces waste and focuses on essentials.
Sprint
Fixed-length event of one month or less that contains all Scrum work and events.
Product Backlog
Emergent, ordered list of what is needed to improve the product.
Product Goal
Commitment for Product Backlog; future product state to plan against.
Sprint Backlog
Sprint Goal, selected Product Backlog Items, and plan for delivering them.
Sprint Goal
Commitment for Sprint Backlog; objective for the Sprint.
Increment
Usable, Done work that is a step toward Product Goal.
Definition of Done
Commitment for Increment; shared quality standard for Done work.
Product Owner
Accountable for maximizing product value.
Scrum Master
Accountable for establishing Scrum and improving Scrum Team effectiveness.
Developers
Accountable for creating a usable Increment each Sprint.
Stakeholder
Person outside the Scrum Team with interest, input, feedback, or impact.
Refinement
Ongoing activity to add detail, order, and clarity to Product Backlog Items.
Timebox
Maximum duration for an event.
Exam-Day Reasoning Heuristics
When two answers seem plausible, prefer the one that:
Increases transparency rather than hiding or smoothing over reality.
Enables inspection and adaptation sooner.
Preserves Scrum accountabilities.
Supports self-management by the Scrum Team.
Protects the Sprint Goal without freezing all learning.
Maintains quality through the Definition of Done.
Uses the Product Owner for value and ordering decisions.
Uses Developers for Sprint Backlog planning and technical execution decisions.
Uses the Scrum Master as coach, facilitator, teacher, and impediment remover, not commander.
Avoids adding non-Scrum roles, phases, approvals, or mandatory practices as if they are required Scrum.
Final Review Checklist
Before practicing more PSM I questions, confirm you can answer these without hesitation:
Name the three Scrum accountabilities and what each is accountable for.
Match each artifact to its commitment.
Explain why the Daily Scrum is not a status meeting.
Distinguish Sprint Review from Sprint Retrospective.
State who can cancel a Sprint and why.
Explain what happens to work that does not meet the Definition of Done.
Identify optional practices that are not required Scrum: velocity, story points, burndown charts, user stories, Sprint 0.
Explain how Product Owner authority differs from stakeholder input.
Explain how Developers own the Sprint Backlog.
Choose coaching and transparency-focused actions for Scrum Master scenarios.
Next step: apply this reference to timed PSM I-style practice questions, then review every missed question against the Scrum Guide concepts behind it.
High-yield exam mindset
The PSM I exam rewards precise understanding of Scrum as defined, not “how my company runs agile.” When choosing an answer, ask:
Is this transparent? Scrum relies on visible work, visible progress, visible quality, and visible decisions.
Does it support inspection and adaptation? Scrum events exist to inspect and adapt specific things.
Does it preserve accountability? Product Owner, Scrum Master, and Developers have distinct accountabilities.
Does it keep quality high? Scrum does not solve schedule pressure by lowering the Definition of Done.
Is it required by Scrum or merely a possible practice? User stories, velocity, burn-down charts, Definition of Ready, release plans, and estimation techniques may be useful, but Scrum does not require them.
Exam trap: Many wrong answers sound reasonable in a traditional project-management setting but add non-Scrum roles, approval gates, handoffs, status reporting, or command-and-control behavior.
Scrum Master Cheat Sheet
The Scrum Master is accountable for Scrum effectiveness. The Scrum Master is a true leader who serves the Scrum Team and the wider organization.
Serves
High-yield examples
Scrum Team
Coaching self-management and cross-functionality; helping focus on valuable Increments; causing impediment removal; ensuring events are positive, productive, and within timebox.
Product Owner
Helping with Product Goal and Product Backlog management; supporting empirical product planning; facilitating stakeholder collaboration when needed.
Organization
Leading, training, and coaching Scrum adoption; helping people understand empirical approaches; removing barriers between stakeholders and Scrum Teams.
Notes and examples
Scrum Master traps
Scenario
Better Scrum answer
Developers are waiting for task assignments.
Coach the team toward self-management; Developers decide how to do the work.
Daily Scrum has become a report to the Scrum Master.
Coach Developers to inspect progress toward the Sprint Goal and adapt their plan.
Management wants lower quality to hit a date.
Protect transparency and the Definition of Done; quality does not decrease.
Stakeholders bypass the Product Owner and direct Developers.
Help everyone respect Product Owner accountability and Scrum Team focus.
Scrum events are mechanical and low value.
Facilitate better understanding of each event’s purpose.
The Scrum Master may facilitate, teach, coach, mentor, and remove or cause the removal of impediments. That does not mean the Scrum Master owns the team’s work or makes product decisions.
Event-by-event traps
Sprint
During the Sprint:
No changes are made that would endanger the Sprint Goal.
Quality does not decrease.
Product Backlog refinement happens as needed.
Scope may be clarified and renegotiated with the Product Owner as more is learned.
Notes and examples
Trap
Correct Scrum view
Sprint scope is completely frozen.
The Sprint Goal is protected; scope can be clarified or renegotiated.
The Sprint can last any length if the project is large.
A Sprint is one month or less.
A hardening Sprint is normal Scrum.
Every Sprint should create a valuable, useful Increment.
Release can happen only after Sprint Review.
Sprint Review is not a release gate.
A Sprint may be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.
Sprint Planning
Sprint Planning addresses three topics:
Topic
Question
Key accountability
Why is this Sprint valuable?
What Sprint Goal will guide the Sprint?
Whole Scrum Team collaborates; Product Owner ensures product direction is clear.
What can be Done this Sprint?
Which Product Backlog items are selected?
Developers select how much they can complete.
How will the chosen work get Done?
What plan will Developers use?
Developers plan the work.
The Sprint Backlog is the Sprint Goal, the selected Product Backlog items, and the plan for delivering them.
Daily Scrum
The Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog.
Common traps:
It is not a status meeting for the Scrum Master.
The “three questions” are not required by Scrum.
Stakeholders do not use it to request updates.
Problems identified in the Daily Scrum may lead to follow-up discussions after the event.
The meeting should be held at the same time and place every working day of the Sprint to reduce complexity.
Sprint Review
The Sprint Review inspects the outcome of the Sprint and determines future adaptations. The Scrum Team and stakeholders collaborate about what was done, what changed, and what to do next.
It is not merely a demo.
It is not a formal acceptance gate.
It is not the first time stakeholders are allowed to see work.
It is not a replacement for ongoing Product Backlog refinement.
Undone work is not presented as part of the Increment.
Sprint Retrospective
The Sprint Retrospective inspects the Scrum Team’s people, interactions, processes, tools, and Definition of Done. The Scrum Team identifies helpful changes to improve effectiveness.
It is not optional because the Sprint “went well.”
It is not only for Developers; the whole Scrum Team participates.
It is not a complaint session without action.
Improvement work can be added to the next Sprint Backlog when appropriate.
Progress toward the Sprint Goal and Sprint Backlog plan
Daily Scrum
Team effectiveness, process, tools, relationships, Definition of Done
Sprint Retrospective
Sprint purpose, selected work, delivery plan
Sprint Planning
Overall risk and learning cycle
Sprint itself
Quick decision rule: if the question asks where stakeholders collaborate on what to do next for the product, think Sprint Review. If it asks where the Scrum Team improves its way of working, think Sprint Retrospective.
Who decides? Quick table
Decision or action
Primary accountability
Product Backlog order
Product Owner
Product Goal
Product Owner accountable; Scrum Team collaborates around it
What Product Backlog items are selected for a Sprint
Developers select; Product Owner clarifies and discusses value
Sprint Goal
Scrum Team creates during Sprint Planning
How Sprint work is done
Developers
Daily plan
Developers
Estimates
Developers
Whether a Product Backlog item is Done
Determined by the Definition of Done
Cancelling a Sprint
Product Owner
Scrum adoption coaching
Scrum Master
Removing organizational barriers to Scrum
Scrum Master helps cause removal; organization may need to act
Releasing an Increment
Product/business decision; Scrum does not make Sprint Review a release gate
“Required by Scrum” versus “optional practice”
PSM I questions often test whether you can distinguish Scrum from complementary practices.
Practice or concept
Required by Scrum?
Review note
Product Backlog
Yes
Artifact.
Sprint Backlog
Yes
Artifact.
Increment
Yes
Artifact.
Product Goal
Yes
Commitment for Product Backlog.
Sprint Goal
Yes
Commitment for Sprint Backlog.
Definition of Done
Yes
Commitment for Increment.
Daily Scrum
Yes
Event for Developers.
User stories
No
Common Product Backlog item format, not required.
Story points
No
Common estimation approach, not required.
Velocity
No
Common metric, not required.
Burn-down or burn-up chart
No
May help forecasting; does not replace empiricism.
Definition of Ready
No
May be used, but not part of Scrum.
Project manager role
No
Scrum defines Product Owner, Scrum Master, and Developers.
Release Sprint or hardening Sprint
No
Quality and integration are part of Done work every Sprint.
Fast comparison: Product Goal vs Sprint Goal vs Definition of Done
Commitment
Attached artifact
Time horizon
Answers the question
Product Goal
Product Backlog
Longer-term
What future product state are we working toward?
Sprint Goal
Sprint Backlog
Current Sprint
Why is this Sprint valuable?
Definition of Done
Increment
Every Increment
What makes work complete and usable?
Last-week review checklist
Use this checklist before doing full mock exams:
Can you explain all three Scrum artifacts and their commitments without notes?
Can you state who is accountable for Product Backlog ordering, estimates, Sprint Backlog planning, and Scrum effectiveness?
Can you distinguish Sprint Review from Sprint Retrospective in scenario questions?
Can you identify non-Scrum additions such as project manager, hardening Sprint, mandatory user stories, and velocity commitments?
Can you explain why the Daily Scrum is not a status meeting?
Can you explain how scope may adapt during a Sprint while the Sprint Goal and quality are protected?
Can you explain why undone work is not part of the Increment?
Can you recognize when an answer violates self-management?
Can you apply empiricism: transparency first, then inspection, then adaptation?