PSM I — Scrum.org Professional Scrum Master I Quick Reference

Last revised: July 1, 2026

Compact Scrum.org PSM I quick reference covering Scrum accountabilities, events, artifacts, commitments, empiricism, Scrum Master decisions, and common exam traps.

How to Use This Quick Reference

This independent Quick Reference is for candidates preparing for the real Scrum.org Professional Scrum Master I (PSM I) exam. It focuses on the Scrum Guide concepts most likely to appear in scenario questions: empiricism, Scrum accountabilities, events, artifacts, commitments, self-management, servant leadership, and common “what should the Scrum Master do?” decisions.

Use this as a final-pass review after reading the Scrum Guide carefully.

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.
Sprint length	Fixed length of one month or less.
Core cycle	Sprint Planning → Daily Scrums → work/refinement/adaptation → Sprint Review → Sprint Retrospective.
Artifacts	Product Backlog, Sprint Backlog, Increment.
Artifact commitments	Product Goal, Sprint Goal, Definition of Done.
Key trap	Scrum is intentionally incomplete. Do not add mandatory phases, documents, sign-offs, or roles and call them Scrum.

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.

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.

Scrum Accountabilities

Scrum uses three accountabilities, all within one Scrum Team.

Accountability	Primary accountability	Owns / is accountable for	Does not mean
Product Owner	Maximizing product value	Product Goal, Product Backlog management, ordering backlog items, making backlog transparent	A committee, project manager, business analyst group, or proxy decision body
Scrum Master	Establishing Scrum as defined in the Scrum Guide	Scrum effectiveness, coaching, facilitation, impediment removal, helping the organization understand Scrum	Team boss, task assigner, status collector, administrator only
Developers	Creating any aspect of a usable Increment each Sprint	Sprint Backlog, quality by adhering to Definition of Done, daily plan adaptation, sizing/estimating work	Only programmers; Developers can include all skills needed to build the product

Product Owner Quick Rules

Rule	Exam implication
One Product Owner per Scrum Team.	If multiple stakeholders disagree, the Product Owner is the single person accountable for ordering and value decisions.
Product Owner may delegate work.	Delegation does not remove Product Owner accountability.
Product Backlog must be transparent, visible, and understood.	Scrum Master may coach Product Owner and organization if backlog is unclear.
Product Owner orders the Product Backlog.	Committees may advise, but they do not replace Product Owner accountability.
Product Owner can cancel a Sprint.	Only the Product Owner has authority to cancel, and only when the Sprint Goal becomes obsolete.

Scrum Master Service Areas

Serves	How the Scrum Master helps	Exam trap
Scrum Team	Coaches self-management and cross-functionality; helps focus on high-value Increment; removes impediments; facilitates events as needed.	Scrum Master does not manage Developers’ tasks.
Product Owner	Helps with Product Goal, Product Backlog management, empirical planning, stakeholder collaboration.	Scrum Master does not order the Product Backlog for the Product Owner.
Organization	Leads, trains, and coaches Scrum adoption; removes barriers; plans implementation; helps stakeholders understand empiricism.	Scrum Master responsibility extends beyond the team room.

Developers Quick Rules

Developers are accountable for	Practical exam meaning
Creating a plan for the Sprint	The Sprint Backlog belongs to Developers.
Instilling quality	Quality is not traded away; Definition of Done is respected.
Adapting plan daily	Daily Scrum is for Developers to inspect progress and adapt.
Holding each other accountable	Self-management replaces external task assignment.
Creating a usable Increment	“Almost done” work that does not meet DoD is not part of the Increment.

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.	Sprint Goal; selected Product Backlog Items; initial plan.
Daily Scrum	15 minutes	Developers; others only if useful and not disruptive	Inspect progress toward Sprint Goal and adapt Sprint Backlog.	Updated plan for next working day.
Sprint Review	Max 4 hours for a one-month Sprint	Scrum Team and stakeholders	Inspect outcome and adapt Product Backlog.	Feedback, collaboration, possible Product Backlog updates.
Sprint Retrospective	Max 3 hours for a one-month Sprint	Scrum Team	Inspect how the Sprint went and plan improvements.	Improvement actions for next Sprint.

Event Distinctions

If the question says…	Think…
“Inspect progress toward the Sprint Goal”	Daily Scrum.
“Inspect the product Increment with stakeholders”	Sprint Review.
“Inspect team process, relationships, tools, and Definition of Done”	Sprint Retrospective.
“Decide why this Sprint is valuable”	Sprint Planning, Sprint Goal.
“Adapt the Product Backlog based on feedback”	Sprint Review or ongoing Product Backlog management.
“Developers synchronize work and adjust their plan”	Daily Scrum, not a status meeting for the Scrum Master.
“Stakeholders accept or reject work”	Trap. Scrum does not define a formal acceptance gate at Sprint Review. Work either meets DoD or it does not.

Sprint Planning Reference

Sprint Planning addresses three topics.

Topic	Question answered	Main accountability
Why is this Sprint valuable?	What value/outcome should the Sprint create?	Product Owner proposes how product value could increase; whole Scrum Team collaborates to define Sprint Goal.
What can be Done this Sprint?	Which Product Backlog Items are selected?	Developers select how much work they believe they can complete; Product Owner discusses objective and items.
How will the chosen work get Done?	What is the initial plan?	Developers plan the work necessary to create an Increment that meets DoD.

Sprint Planning Traps

Trap answer	Better PSM I reasoning
Product Owner assigns Sprint work to Developers.	Developers select the amount of work and create the plan.
Scrum Master decides capacity and commits the team.	Scrum Master facilitates and coaches; Developers manage their plan.
Sprint Backlog is fixed after Sprint Planning.	Sprint Backlog is emergent and adapted throughout the Sprint.
Sprint Goal is optional if enough backlog items are selected.	Sprint Goal is the commitment for the Sprint Backlog.
Team commits to finishing every selected item regardless of discoveries.	The team commits to the Sprint Goal; scope may be negotiated without endangering it.

Daily Scrum Reference

Point	Correct PSM I interpretation
Purpose	Inspect progress toward the Sprint Goal and adapt the Sprint Backlog.
Timebox	15 minutes.
Required attendees	Developers.
Scrum Master role	Ensure the event happens and is positive/productive/timeboxed if needed; Developers run it.
Product Owner attendance	Allowed if they are actively working on Sprint Backlog items or if useful, but the event is for Developers.
Format	Not prescribed. The three traditional questions are optional, not mandatory.
Misuse	Reporting status to Scrum Master, assigning tasks, solving every technical issue during the event.

Sprint Review vs Sprint Retrospective

Dimension	Sprint Review	Sprint Retrospective
Inspect	Product outcome, Increment, market/stakeholder feedback, progress toward Product Goal.	People, interactions, process, tools, Definition of Done, ways of working.
Participants	Scrum Team and stakeholders.	Scrum Team.
Main adaptation	Product Backlog and future product direction.	Team process and improvement plan.
Tone	Collaborative working session, not a demo-only meeting.	Improvement-focused internal inspection.
Common trap	Treating Review as a sign-off gate.	Skipping it because the Sprint went well.

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.

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.

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.

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.	Removing events or making timeboxes meaningless.
Organization imposes detailed command-and-control process.	Coach organization on Scrum, empiricism, and self-management; remove impediments.	Accepting process rules that undermine Scrum without challenge.
Conflict occurs within the team.	Encourage openness, respect, and team-owned resolution; facilitate if useful.	Solving every interpersonal issue by command.
Developers lack required skills.	Coach cross-functionality, learning, collaboration, and organizational support.	Creating permanent component silos or handoff sub-teams.
Product Backlog is unclear.	Help Product Owner improve transparency, ordering, and refinement.	Ordering the Product Backlog yourself.

Product Owner Decision Table

Scenario	Product Owner should…	PSM I trap
Stakeholders disagree on priorities.	Decide ordering after considering input and value.	Letting a committee replace the Product Owner.
Developers say selected work is too much.	Collaborate on scope while preserving Sprint Goal.	Forcing original Sprint scope.
New urgent request appears mid-Sprint.	Discuss with Developers and consider Sprint Goal impact.	Automatically injecting work into the Sprint.
Sprint Goal becomes obsolete.	Consider cancelling the Sprint.	Cancelling because some tasks are late.
Product Backlog lacks transparency.	Improve clarity, ordering, and communication.	Treating backlog maintenance as only Developers’ responsibility.
Stakeholders want a release.	Decide release timing based on value, readiness, and context.	Assuming release only happens at Sprint end.

Developers Decision Table

Scenario	Developers should…	Avoid
Work is discovered during the Sprint.	Add/adapt work in Sprint Backlog as needed to meet Sprint Goal.	Waiting for Scrum Master permission.
They cannot complete all selected PBIs.	Collaborate with Product Owner on scope and Sprint Goal.	Hiding the issue until Sprint Review.
A PBI does not meet DoD.	Do not include it in the Increment.	Calling it Done because coding is complete.
Daily Scrum is not helping.	Change the format while preserving purpose and timebox.	Skipping Daily Scrum.
Quality is under pressure.	Uphold Definition of Done and make tradeoffs transparent.	Lowering quality to increase apparent velocity.
Technical debt threatens delivery.	Make impact transparent; plan work needed to maintain quality and adaptability.	Treating technical debt as invisible or outside the product work.

Scrum Team Structure and Self-Management

Concept	Correct PSM I meaning
Self-managing	Scrum Team decides who does what, when, and how.
Cross-functional	Scrum Team has all skills needed to create value each Sprint.
No sub-teams	No testing team, architecture team, analysis team, or component team inside the Scrum Team as Scrum-defined sub-teams.
No hierarchy within Scrum Team	Accountabilities differ, but members work as peers.
Small team principle	Scrum Team should be small enough to remain nimble and large enough to complete significant work.
Stakeholders	Important collaborators, especially with Product Owner and during Sprint Review, but not Scrum accountabilities.
Managers	May exist in the organization, but Scrum does not define a manager role inside the Scrum Team.

Definition of Done vs Acceptance Criteria

Dimension	Definition of Done	Acceptance Criteria
Applies to	Increment, and work included in it.	Usually a specific Product Backlog Item.
Purpose	Shared quality standard for transparency and releasability.	Clarifies expected behavior or conditions for a backlog item.
Ownership/accountability	Scrum Team uses it; Developers adhere to it; organizational standards may apply.	Often discussed by Product Owner and Developers during refinement/planning.
If not met	Work is not part of the Increment.	Item may not satisfy expected product need.
Exam trap	DoD is not optional and not replaced by acceptance criteria.	Acceptance criteria alone do not prove the Increment is Done.

Product Goal, Sprint Goal, and Increment Distinctions

Goal / outcome	Scope	Purpose	Commitment for
Product Goal	Longer-term product objective	Guides the Product Backlog toward a future product state.	Product Backlog
Sprint Goal	Current Sprint objective	Provides focus and flexibility for Sprint work.	Sprint Backlog
Increment	Done product work	Creates a usable step toward the Product Goal.	Definition of Done

Goal Traps

Trap	Correction
Sprint Goal is a list of all selected PBIs.	Sprint Goal is an objective, not a task list.
Product Goal changes every Sprint by default.	Product Goal is a longer-term target; Product Backlog evolves toward it.
Completing tasks equals success even if no usable Increment exists.	Scrum requires a Done, usable Increment each Sprint.
Sprint Review is where the Sprint Goal is first inspected.	Progress toward Sprint Goal is inspected throughout the Sprint, especially at Daily Scrum.

Release, Done, and Potentially Releasable Work

Statement	PSM I interpretation
Every Sprint must create a usable Increment.	Correct.
Every Sprint must release to users.	Not required by Scrum.
Done work can be released before Sprint Review.	Correct; Scrum does not restrict releases to Sprint end.
Sprint Review is required before release.	Not required by Scrum.
Undone work can be shown at Sprint Review.	It may be discussed, but it is not part of the Increment.
A hardening Sprint is needed before release.	Trap. Each Sprint should create Done usable work.

Point	PSM I reference
Status	Ongoing activity, not a formal Scrum event.
Purpose	Break down and further define Product Backlog Items into smaller, more precise items.
Participants	Scrum Team members collaborate as needed; stakeholders may provide input.
Product Owner role	Accountable for Product Backlog management and ordering.
Developers role	Contribute estimates, technical insight, decomposition, and feasibility understanding.
Timebox	No official Scrum timebox in the current Scrum Guide.
Trap	Refinement does not replace Sprint Planning.

Estimation, Velocity, and Forecasting

Scrum does not require a specific estimation technique, metric, or chart.

Concept	Exam-safe interpretation
Estimate	A forecast made with current knowledge; not a guarantee.
Velocity	Optional historical measure some teams use; not defined as a required Scrum artifact.
Story points	Optional technique; not required by Scrum.
Burndown/burnup charts	Optional practices; can help transparency but are not Scrum artifacts.
Commitment	The Scrum Team commits to goals and quality, not to maximizing velocity.
Forecast	Product Owner and Developers use empirical evidence to make planning decisions.

Metrics Traps

Trap	Better answer
Use velocity to compare teams.	Avoid; context differs and it can damage transparency.
Increase velocity by lowering DoD.	Wrong; quality and transparency suffer.
Scrum Master reports individual performance.	Scrum emphasizes team accountability and self-management.
A tool-generated report replaces inspection.	Tools can help, but real inspection and adaptation are required.

Common PSM I Scenario Patterns

Mid-Sprint Change

If…	Then…
Change supports Sprint Goal	Product Owner and Developers may collaborate to adjust Sprint Backlog.
Change threatens Sprint Goal	Make impact transparent; negotiate scope; consider whether Sprint Goal remains valid.
Sprint Goal is obsolete	Product Owner may cancel the Sprint.
Stakeholder demands direct assignment	Product Owner orders Product Backlog; Developers manage Sprint Backlog.

Incomplete Work at Sprint End

Situation	Correct handling
Work meets DoD	Include in Increment.
Work does not meet DoD	Do not include in Increment.
PBI partly complete	Return to Product Backlog or rework as appropriate; Product Owner reorders.
Team wants to extend Sprint	Do not extend. Keep cadence and inspect/adapt.
Repeated spillover	Inspect causes in Retrospective: refinement, sizing, dependencies, skills, interruptions, DoD, technical debt.

Quality Pressure

Pressure	Scrum-aligned response
“Skip tests to hit the date.”	Uphold DoD; make impact transparent.
“Call it Done and fix later.”	Not Done means not part of Increment.
“Create a hardening Sprint.”	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.

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.

Scenario Guide

Scrum Theory, Values, and Empiricism