PSM I — Scrum.org Professional Scrum Master I Scenario Practice Guide

How to approach PSM I scenario questions

Scenario questions on the Scrum.org Professional Scrum Master I (PSM I) exam often test whether you can apply Scrum in a realistic situation, not just recall a definition. A short scenario may describe a stakeholder request, a struggling Scrum Team, unfinished work, an event being misused, or pressure from management.

Your task is to slow down and identify the Scrum decision point:

• Who is accountable here?
• What part of Scrum is involved?
• What has become unclear, risky, or non-transparent?
• What should happen next according to Scrum?
• Which answer best preserves empiricism, self-management, and the Scrum accountabilities?

This guide is for independent exam preparation and focuses on public Scrum reasoning habits. It is not affiliated with Scrum.org.

Start by identifying the accountability

In PSM I scenarios, the role or accountability usually determines the correct direction of the answer. Before choosing an option, ask: “Whose decision is this?”

Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. In scenarios, this usually means the Scrum Master helps the Scrum Team and organization understand and apply Scrum.

Look for actions such as:

• Coaching the Scrum Team, Product Owner, Developers, or organization
• Helping remove impediments to the Scrum Team’s progress
• Facilitating when useful or requested
• Helping events achieve their purpose
• Promoting transparency, inspection, and adaptation
• Helping people understand Scrum accountabilities, events, artifacts, and commitments

A Scrum Master scenario is rarely about the Scrum Master taking over another accountability. If an answer has the Scrum Master assigning tasks, ordering the Product Backlog, deciding which Product Backlog items are selected, or approving the Increment, check it carefully against Scrum accountabilities.

Product Owner

The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team’s work. The Product Owner is also accountable for effective Product Backlog management.

In scenarios, the Product Owner is central when the issue involves:

• Product Backlog ordering
• Product Goal clarity
• Stakeholder input and value decisions
• Product Backlog transparency
• Deciding what is most valuable next
• Collaborating with Developers about scope, value, and trade-offs

The Product Owner may delegate work, but remains accountable. If a scenario asks who decides Product Backlog order, value priority, or product direction, anchor your reasoning in the Product Owner accountability.

Developers

The Developers are accountable for creating a usable Increment each Sprint. They manage their own work and create the plan for the Sprint Backlog.

Developer-centered scenarios often involve:

• How work is done
• Who performs which work
• Technical decisions
• Sprint Backlog adaptation
• Meeting the Definition of Done
• Inspecting progress toward the Sprint Goal
• Creating a Done Increment

If an answer has a manager, Scrum Master, or Product Owner assigning work to individual Developers, pause. Scrum Teams are self-managing.

Scrum Team

Some scenarios are about the Scrum Team as a whole. The Scrum Team is responsible for all product-related activities and works together to create value every Sprint.

Use the Scrum Team lens when the issue involves:

• Collaboration across accountabilities
• Product Goal or Sprint Goal understanding
• Quality and transparency
• Inspection and adaptation
• Working with stakeholders
• Improving effectiveness

Locate the scenario in the Sprint

PSM I scenario questions often hinge on timing. The same fact can imply a different answer depending on whether it happens before Sprint Planning, during the Sprint, at the Sprint Review, or in the Sprint Retrospective.

Before or during Sprint Planning

Ask what must be clear enough for the Scrum Team to plan:

• Why is this Sprint valuable?
• What can be Done this Sprint?
• How will the selected work be accomplished?
• Is there a clear Sprint Goal?
• Are Product Backlog items sufficiently understood?

The Product Owner proposes how the product could increase value and utility. The Developers select items from the Product Backlog and create the plan. The entire Scrum Team collaborates to define the Sprint Goal.

During the Sprint

During the Sprint, focus on the Sprint Goal, the Sprint Backlog, quality, and transparency.

Good reasoning questions include:

• Does the new information endanger the Sprint Goal?
• Is the Sprint Backlog being adapted by the Developers as more is learned?
• Is the Product Owner collaborating with Developers on scope and trade-offs?
• Is quality being preserved?
• Is the work still expected to produce a usable Increment?

Scrum allows learning during the Sprint. The plan can evolve. However, changes should not endanger the Sprint Goal, and quality does not decrease.

At the Daily Scrum

The Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.

When a scenario mentions the Daily Scrum, ask:

• Are Developers using it to inspect and adapt?
• Is it being turned into a status report?
• Is someone outside the Developers directing the event?
• Is the event helping progress toward the Sprint Goal?

The Scrum Master does not need to run the Daily Scrum. The structure is set by the Developers, provided it supports progress toward the Sprint Goal.

At the Sprint Review

The Sprint Review is for inspecting the outcome of the Sprint and determining future adaptations. It is not merely a presentation or an approval gate.

When a scenario mentions the Sprint Review, ask:

• Is the Increment being inspected with stakeholders?
• Is feedback being used to adapt the Product Backlog?
• Is the conversation about the product and future direction?
• Is only Done work being treated as part of the Increment?

A strong answer usually supports collaboration, transparency, and adaptation of the Product Backlog based on what was learned.

At the Sprint Retrospective

The Sprint Retrospective is for the Scrum Team to inspect how the last Sprint went and plan improvements.

When a scenario mentions recurring problems, team friction, process issues, quality problems, or collaboration issues, ask whether the Sprint Retrospective is the right place to inspect and improve. Some issues must be handled immediately, but systemic improvement often belongs in the Retrospective.

Find the actual problem, not the loudest detail

Many scenarios include emotional or distracting facts: an angry stakeholder, a demanding manager, a missed expectation, a technical problem, or a team disagreement. Those details matter only if they change the Scrum decision.

Separate the scenario into three parts:

1. Facts: What is explicitly stated?
2. Scrum context: Which accountability, event, artifact, or commitment is involved?
3. Decision point: What must be decided or done next?

For example:

• “A stakeholder is upset” may really be a Product Backlog ordering or Sprint Review feedback issue.
• “Developers are behind” may really be a transparency and Sprint Goal inspection issue.
• “The Scrum Master is asked to assign tasks” may really be a self-management issue.
• “Work is almost finished” may really be a Definition of Done issue.
• “Management wants a report” may really be an organizational transparency and coaching issue.

Do not answer the emotion. Answer the Scrum problem.

Use Scrum’s decision sequence

When the scenario asks for the best next step, use this sequence before reading the answer choices too deeply.

1. Restore transparency

If the facts are unclear, hidden, or misleading, the next step is often to make the situation transparent.

Examples:

• Make unfinished work visible.
• Clarify whether work meets the Definition of Done.
• Inspect progress toward the Sprint Goal.
• Make Product Backlog ordering and Product Goal clarity visible.
• Help stakeholders understand what the Increment does and does not include.

Transparency comes before meaningful inspection and adaptation.

2. Inspect with the right people

After transparency, ask who should inspect the situation.

• Developers inspect progress toward the Sprint Goal at the Daily Scrum.
• The Scrum Team and stakeholders inspect the Increment at the Sprint Review.
• The Scrum Team inspects its effectiveness at the Sprint Retrospective.
• The Product Owner collaborates with stakeholders and the Scrum Team on value and Product Backlog decisions.
• The Scrum Master helps people use Scrum effectively.

A strong answer puts the issue in front of the people who have the right accountability.

3. Adapt within Scrum

The best answer usually adapts the plan, Product Backlog, Sprint Backlog, or working approach without breaking Scrum.

Examples:

• Developers adapt the Sprint Backlog during the Sprint.
• The Product Owner adapts Product Backlog ordering based on new information.
• The Scrum Team improves its process after inspection.
• The Scrum Master coaches the organization when behavior conflicts with Scrum.
• The team maintains the Definition of Done rather than lowering quality.

4. Escalate only when appropriate

Not every problem requires escalation. A Scrum Master may help remove impediments, including organizational impediments, but many scenarios should first be handled through collaboration, coaching, transparency, and inspection.

Escalation is more defensible when the issue is outside the Scrum Team’s ability to resolve or when an organizational impediment blocks progress. It is less defensible when the answer bypasses Scrum accountabilities or prevents the team from self-managing.

Determine whether the answer should be action, communication, or analysis

Scenario questions often ask what should happen next. The best answer depends on the type of problem.

Choose communication when people are misaligned

If the scenario shows misunderstanding, conflicting expectations, unclear value, or stakeholder confusion, look for answers involving collaboration and clarification.

Examples:

• Product Owner collaborates with stakeholders about value and ordering.
• Scrum Master coaches a manager on Scrum accountabilities.
• Developers discuss trade-offs with the Product Owner.
• Scrum Team makes progress and impediments transparent.

Choose analysis when inspection is needed before action

If the scenario does not provide enough information to justify a major action, the best answer may involve inspecting the situation first.

Examples:

• Inspect whether the Sprint Goal is still achievable.
• Determine whether work meets the Definition of Done.
• Review the Product Backlog with the Product Owner.
• Discuss the impact of a requested change before accepting it into the Sprint.

Choose action when Scrum clearly defines the next step

Some scenarios provide enough facts for a direct Scrum-based response.

Examples:

• Work that is not Done is not part of the Increment.
• The Product Owner orders the Product Backlog.
• Developers manage the Sprint Backlog.
• The Daily Scrum is for Developers.
• Only the Product Owner has the authority to cancel a Sprint.

The best answer is not always the most forceful action. It is the action that best fits Scrum.

Read answer choices through Scrum principles

After identifying the decision point, evaluate each answer using these questions.

Does it preserve empiricism?

Scrum is founded on empiricism. A good answer should support transparency, inspection, and adaptation.

Be cautious if an answer:

• Hides bad news
• Treats plans as fixed regardless of learning
• Avoids inspection
• Prevents stakeholders from seeing the real Increment
• Changes reports instead of addressing reality

Does it respect self-management?

Scrum Teams are self-managing. They decide who does what, when, and how.

Be cautious if an answer:

• Assigns tasks to Developers from outside the Developers
• Has the Scrum Master direct technical work
• Has management decide Sprint Backlog details
• Removes the Developers from planning how to do the work

Does it protect quality?

Quality does not decrease during the Sprint. The Definition of Done is central to deciding whether work is part of the Increment.

Be cautious if an answer:

• Counts unfinished work as Done
• Weakens the Definition of Done to meet a date
• Presents incomplete work as part of the Increment
• Hides quality concerns until later

Does it keep the event’s purpose intact?

Each Scrum event has a purpose. Strong answers use the event for that purpose.

Use these quick checks:

• Sprint Planning: Why is the Sprint valuable, what can be Done, and how will it be done?
• Daily Scrum: Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog.
• Sprint Review: Scrum Team and stakeholders inspect the outcome and adapt future direction.
• Sprint Retrospective: Scrum Team inspects how it worked and plans improvements.

Does it keep accountabilities clear?

A tempting answer may seem helpful but assign the decision to the wrong person.

Use these anchors:

• Product Owner: value, Product Backlog, Product Goal, ordering.
• Developers: Sprint Backlog, technical approach, Done Increment.
• Scrum Master: Scrum effectiveness, coaching, facilitation, impediment removal.
• Scrum Team: product-related collaboration and continuous improvement.

Handle change requests in scenarios

Change requests are common in PSM I-style scenarios because they test whether you understand adaptation without abandoning the Sprint Goal.

When a new request appears during the Sprint, ask:

• Who is requesting the change?
• Does the Product Owner understand its value?
• Would the change endanger the Sprint Goal?
• Can the Developers adapt the Sprint Backlog without reducing quality?
• Should the item be ordered in the Product Backlog for a future Sprint?
• Has the Sprint Goal become obsolete?

A defensible answer usually involves Product Owner and Developers collaborating. The Product Owner may clarify value and ordering; the Developers assess impact on the Sprint Backlog and Sprint Goal. If the Sprint Goal becomes obsolete, the Product Owner has the authority to cancel the Sprint.

Avoid assuming every change must be rejected. Also avoid assuming every urgent request should interrupt the Sprint. Use the Sprint Goal as the decision anchor.

Handle unfinished work scenarios

Unfinished work scenarios test whether you understand the Increment and Definition of Done.

Ask:

• Does the work meet the Definition of Done?
• Is it usable?
• Is it part of the Increment?
• Should it be made transparent at the Sprint Review?
• Should the Product Backlog be adapted?
• Should the Scrum Team inspect why it was not completed?

If work is not Done, it is not part of the Increment. It may be discussed transparently, and the Product Backlog may be adapted. The team can inspect causes and improvements, often in the Sprint Retrospective.

The defensible answer protects transparency and quality.

Handle stakeholder pressure scenarios

Stakeholder scenarios often include urgency, dissatisfaction, or conflicting expectations. Do not let pressure override Scrum accountabilities.

Read for:

• Is the stakeholder providing feedback?
• Is the Product Owner using stakeholder input to manage value?
• Is the Sprint Review being used to inspect the Increment?
• Is the Product Backlog transparent?
• Is the Scrum Team being asked to bypass the Product Owner?
• Is the team being pressured to reduce quality or ignore the Sprint Goal?

A strong answer usually keeps stakeholder collaboration active while preserving Product Owner accountability for Product Backlog decisions.

Handle management intervention scenarios

Management or leadership may appear in scenarios asking for status reports, task assignments, deadlines, or direct control over Developers.

Your reasoning should be calm:

• What is management trying to achieve?
• Is there a transparency problem?
• Is Scrum being misunderstood?
• Does the answer preserve self-management?
• Should the Scrum Master coach the organization?
• Is there an organizational impediment to remove?

The Scrum Master helps the organization understand and enact Scrum. That does not mean blocking all management interest. It means helping create transparency and alignment without turning Scrum events into command-and-control mechanisms.

Handle conflict inside the Scrum Team

Team conflict scenarios usually test facilitation, self-management, and accountability.

Ask:

• Is the conflict about value, scope, technical approach, quality, or collaboration?
• Which accountability owns the decision?
• Is facilitation needed?
• Should the Scrum Team inspect the issue in the Retrospective?
• Is an immediate impediment blocking progress?
• Would a directive answer reduce self-management?

A strong Scrum Master answer often involves coaching or facilitating so the people with the right accountability can resolve the issue. The Scrum Master should not become the team’s manager or decision-maker.

Mini walkthroughs

Scenario pattern: urgent stakeholder request mid-Sprint

A stakeholder asks for an urgent feature during the Sprint. The Product Owner wants it done immediately.

Read it this way:

• Timing: during the Sprint
• Main concern: impact on the Sprint Goal
• Accountabilities: Product Owner manages value and Product Backlog; Developers manage Sprint Backlog
• Decision point: whether and how to adapt without endangering the Sprint Goal or reducing quality

Most defensible direction:

• Product Owner and Developers collaborate about value, impact, and the Sprint Goal.
• If appropriate, the Sprint Backlog may be adapted.
• If the request should wait, the Product Owner orders it in the Product Backlog.
• If the Sprint Goal becomes obsolete, the Product Owner may cancel the Sprint.

Scenario pattern: work is nearly finished but not Done

Developers say a Product Backlog item is “almost done” at the end of the Sprint.

Read it this way:

• Timing: near Sprint Review
• Main concern: Definition of Done and Increment transparency
• Accountabilities: Developers create a Done Increment; Scrum Team maintains transparency
• Decision point: whether incomplete work can be treated as part of the Increment

Most defensible direction:

• If the work does not meet the Definition of Done, it is not part of the Increment.
• The situation should be transparent.
• The Product Backlog may be adapted.
• The Scrum Team can inspect causes and improvements.

Scenario pattern: Daily Scrum becomes a status meeting

A manager attends the Daily Scrum and asks each Developer for a status update.

Read it this way:

• Event: Daily Scrum
• Main concern: event purpose
• Accountabilities: Developers use the event to inspect progress toward the Sprint Goal
• Scrum Master angle: coach and help Scrum be understood

Most defensible direction:

• Keep the Daily Scrum focused on Developers inspecting and adapting their plan.
• The Scrum Master may coach the manager and organization on the purpose of the event.
• Transparency can be provided without repurposing the Daily Scrum into a management report.

Scenario pattern: Product Owner and Developers disagree about Sprint scope

The Product Owner wants more items added; Developers are concerned the Sprint Goal is at risk.

Read it this way:

• Timing: during the Sprint
• Main concern: Sprint Goal and scope negotiation
• Accountabilities: Product Owner manages value; Developers manage Sprint Backlog
• Decision point: how to adapt collaboratively

Most defensible direction:

• Product Owner and Developers collaborate.
• The Sprint Goal guides trade-off decisions.
• Scope may be clarified or renegotiated if the Sprint Goal is protected.
• The Scrum Master may facilitate if helpful.

High-value facts to keep active while answering

Keep these Scrum anchors ready during scenario practice:

• Scrum is based on transparency, inspection, and adaptation.
• The Scrum Team is self-managing.
• The Product Owner is accountable for maximizing value and Product Backlog management.
• The Developers are accountable for creating a usable Increment each Sprint.
• The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
• The Product Backlog commitment is the Product Goal.
• The Sprint Backlog commitment is the Sprint Goal.
• The Increment commitment is the Definition of Done.
• Only Done work is part of the Increment.
• The Sprint Goal provides focus and flexibility during the Sprint.
• The Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog.
• The Sprint Review is for inspecting the outcome and adapting future direction.
• The Sprint Retrospective is for inspecting how the Scrum Team worked and planning improvements.
• The Product Owner has the authority to cancel a Sprint if the Sprint Goal becomes obsolete.

A fast checklist for final review

Before selecting an answer, ask:

1. What is the real decision point?
2. Which Scrum accountability owns the decision?
3. Which event, artifact, or commitment is involved?
4. Is the answer transparent?
5. Does it support inspection and adaptation?
6. Does it preserve self-management?
7. Does it protect the Definition of Done and product quality?
8. Does it use the event for its intended purpose?
9. Is escalation necessary, or would coaching and collaboration solve it first?
10. Can I justify the answer using Scrum, not personal management preference?

If you cannot explain your chosen answer in one sentence using Scrum terms, reread the scenario.

Practice method for scenario mastery

For each practice question, write a short rationale after answering:

• Accountability: Who owns the decision?
• Scrum element: Which event, artifact, commitment, or principle applies?
• Next step: What should happen now?
• Why not the others: Which answer choices violate accountabilities, transparency, self-management, or quality?

Example rationale:

“Because the issue affects Sprint scope during the Sprint, the Product Owner and Developers should collaborate using the Sprint Goal as the guide; the Scrum Master should not assign work or force a decision.”

This habit builds the reasoning speed needed for exam conditions.

Practical next step

Use scenario practice in short timed sets. After each set, tag missed questions by Scrum area: accountabilities, events, artifacts, commitments, Done, Sprint changes, or Scrum Master service. Then drill the weakest topic and finish with a full mock exam to practice choosing the most defensible Scrum answer under time pressure.