PSM I — Scrum.org Professional Scrum Master I Quick Review
Quick Review for Scrum.org Professional Scrum Master I (PSM I): core Scrum accountabilities, events, artifacts, commitments, and common exam traps.
Quick Review purpose
This Quick Review is for candidates preparing for the real Scrum.org Professional Scrum Master I (PSM I), exam code PSM I, from Scrum.org. Use it to refresh the highest-yield Scrum concepts before moving into topic drills, mock exams, and detailed explanations.
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.
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 in one page
| Area | Core idea | Exam focus |
|---|---|---|
| Theory | Scrum is founded on empiricism and lean thinking. | Transparency, inspection, adaptation; reducing waste. |
| Scrum Team | One Product Owner, one Scrum Master, and Developers. | No sub-teams or hierarchies inside the Scrum Team. |
| Accountabilities | Each accountability has a clear purpose. | Do not let the Scrum Master become a project manager or the Product Owner become a committee. |
| Events | Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. | 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 Scrum values
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 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. | Product Goal, Product Backlog ordering, Product Backlog clarity. | 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 Quick Review
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.
Scrum Master Quick Review
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. |
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.
Developers Quick Review
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 Quick Review
All Scrum events are opportunities for inspection and adaptation. Events are timeboxed; the timebox is a maximum, not a required duration.
| Event | Timebox | Participants | Purpose | Key output or adaptation |
|---|---|---|---|---|
| Sprint | One month or less | Scrum Team | Container for all other events; turn ideas into value. | Done, valuable, useful Increment or Increments. |
| Sprint Planning | Maximum 8 hours for a one-month Sprint | Scrum Team; others may be invited for advice | Decide why the Sprint is valuable, what can be Done, and how the work will be done. | Sprint Goal and Sprint Backlog. |
| Daily Scrum | 15 minutes | Developers; Product Owner/Scrum Master participate if working as Developers | Inspect progress toward the Sprint Goal and adapt the Sprint Backlog. | Updated daily plan. |
| Sprint Review | Maximum 4 hours for a one-month Sprint | Scrum Team and stakeholders | Inspect the outcome of the Sprint and adapt future direction. | Product Backlog may be adjusted. |
| Sprint Retrospective | Maximum 3 hours for a one-month Sprint | Scrum Team | Inspect how the last Sprint went and plan improvements. | Improvement actions, often added to next Sprint Backlog. |
For shorter Sprints, Sprint Planning, Sprint Review, and Sprint Retrospective are usually shorter. The Daily Scrum remains a 15-minute event.
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.
| 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.
Common traps:
- 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.
Common traps:
- 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.
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.
Inspection and adaptation by event
| Inspect/adapt target | Event |
|---|---|
| Product direction, Product Goal progress, stakeholder feedback, Product Backlog | Sprint Review |
| 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. |
Common PSM I scenario patterns
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.
Fast comparison: Sprint Review vs Sprint Retrospective
| Feature | Sprint Review | Sprint Retrospective |
|---|---|---|
| Main focus | Product outcome and future product direction. | Scrum Team effectiveness and improvement. |
| Participants | Scrum Team and stakeholders. | Scrum Team. |
| Inspects | Increment, progress toward Product Goal, market/user/context changes. | 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. |
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?
How to use question-bank practice after this review
After reading this Quick Review, move into PM Mastery practice:
- Start with topic drills on Scrum accountabilities, events, artifacts, and commitments.
- Review detailed explanations, especially for answers that looked plausible but violated Scrum accountability or transparency.
- Track traps, not just scores. Write down whether you missed a question because of event purpose, who-decides authority, Definition of Done, or optional-practice confusion.
- Then use mock exams to practice speed and exam-style decision-making.
- Return to the Scrum Guide language whenever an explanation reveals a weak concept.
Practical next step: begin with a focused PSM I question bank session on Scrum events and accountabilities, then review every missed item with detailed explanations before attempting a full mock exam.
Continue in PM Mastery
Use this Quick Review as a final concept map, then move into PM Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original PM Mastery practice items; they are not official Scrum.org questions, copied live-exam content, or exam dumps.