Practice Scrum.org PSM I with free sample questions, timed mock exams, and detailed explanations for Scrum roles, events, and decision-making.
PSM I is Scrum.org’s core Scrum Master assessment for practitioners who need precise Scrum Guide understanding under time pressure. If you are searching for PSM I sample exam questions, a practice test, or an exam simulator, this is the main PM Mastery page to start on web and continue on iOS or Android with the same account.
Start a practice session for Scrum.org Professional Scrum Master I (PSM I) below, or open the full app in a new tab. For the best experience, open the full app in a new tab and navigate with swipes/gestures or the mouse wheel—just like on your phone or tablet.
Open Full App in a New TabA small set of questions is available for free preview. Subscribers can unlock full access by signing in with the same account they use on web and mobile.
Use on iPhone or Android too: PM Mastery on the App Store or PM Mastery on Google Play using the same account you use on web. The same subscription works across web and mobile.
PSM I rewards precision. Strong performance usually comes from knowing exactly what Scrum says about accountabilities, events, commitments, empiricism, and practical Scrum Master choices.
| Topic | Weight | Estimated questions |
|---|---|---|
| Scrum Theory, Values, and Empiricism | 15% | 12 |
| Scrum Team and Accountabilities | 25% | 20 |
| Scrum Events and Timeboxes | 25% | 20 |
| Artifacts, Commitments, and Done | 25% | 20 |
| Applying Scrum in Practice | 10% | 8 |
These sample questions include the same mix of single-answer and multiple-response items you should practice for PSM I. Use them to check your readiness here, then move into the full PM Mastery question bank for broader timed coverage.
Topic: Artifacts, Commitments, and Done
Mid-Sprint, the Developers learn a key assumption is wrong.
Exhibit: Sprint Backlog (excerpt)
Sprint Goal: Users can reset passwords via email.
PBI-12: Reset email flow (In Progress)
- Build email template (Done)
- Integrate email provider API (In Progress)
Note: Provider has strict rate limits; needs queue + retry.
PBI-15: Reset token validation (Not Started)
What is the best next action for the Developers, based on the exhibit?
Best answer: D
Explanation: The Sprint Backlog is a plan by and for the Developers, and it is expected to evolve during the Sprint as more is learned. Discovering rate limits creates new necessary work, so the Developers should make this transparent by updating the Sprint Backlog and re-planning. If the discovery threatens the Sprint Goal, they collaborate with the Product Owner to adjust scope while keeping the Sprint Goal in focus.
In Scrum, the Sprint Backlog is owned by the Developers and is intentionally emergent: it is updated throughout the Sprint as the Developers learn more. The exhibit shows a new constraint (rate limits) that implies additional work (queue + retry) to achieve the Sprint Goal of password reset via email. The right response is to make this learning transparent by updating the Sprint Backlog (add tasks, adjust the plan) and then inspect whether the Sprint Goal is still achievable. If meeting the Sprint Goal is at risk, the Developers and Product Owner collaborate to adapt the scope of work selected for the Sprint while keeping the Sprint Goal intact; the Sprint Goal is not changed casually and only the Product Owner can cancel a Sprint.
Key takeaway: adapt the Sprint Backlog continuously, and involve the Product Owner when the Sprint Goal/value trade-offs change.
Topic: Scrum Team and Accountabilities
Midway through a Sprint, an external manager emails the Developers with two new “must-do” items and expects them to start immediately. The Scrum Team is concerned about being directed during the Sprint.
Which Scrum concept best applies to this situation?
Best answer: C
Explanation: Scrum relies on self-management: the Scrum Team manages its own work, and the Developers own and adapt the Sprint Backlog to meet the Sprint Goal. External managers can raise requests, but they do not assign work to the Developers during the Sprint. The team can collaborate with the Product Owner to decide what to do with the new request.
The core concept is Scrum Team self-management. During a Sprint, the Developers are accountable for the Sprint Backlog and for adapting their plan as they learn more. New requests from outside the Scrum Team should be treated as input and discussed with the Product Owner; the Developers then decide how (or whether) to incorporate changes while protecting the Sprint Goal.
A practical way to handle it is:
External management directing work bypasses self-management and reduces transparency around the Sprint Goal and Sprint Backlog decisions.
Topic: Applying Scrum in Practice
Midway through a Sprint, the Developers discover that a third-party API they planned to use has been deprecated. Two Product Backlog Items in the Sprint Backlog depend on it and cannot be completed as planned. The Sprint Goal (“Users can complete checkout”) is still valuable.
What is the best next step?
Best answer: A
Explanation: The Sprint Backlog is a plan by and for the Developers and it is expected to change as more is learned. Since the Sprint Goal is still valuable, the right response is to inspect the impact of the new information and adapt by collaborating with the Product Owner to adjust scope and the Sprint Backlog.
In Scrum, learning during the Sprint is normal, so plans must be adaptable. When new information makes some Sprint Backlog work invalid, the Scrum Team should inspect the impact and adapt immediately. The Developers update the Sprint Backlog as an emergent plan, and they collaborate with the Product Owner to renegotiate which work best supports the Sprint Goal given the new constraint. Cancelling a Sprint is a Product Owner decision and is intended for when the Sprint Goal becomes obsolete, not simply because some items need to change. The key takeaway is to replan toward the Sprint Goal rather than add non-Scrum control processes or postpone adaptation.
Topic: Scrum Theory, Values, and Empiricism
Mid-Sprint, a stakeholder discovers a new regulation and asks the Scrum Team to build a compliance feature immediately. The stakeholder asks the Scrum Master to “prioritize it” and tell the Developers to swap it into the current Sprint.
Which response is most consistent with Scrum accountabilities?
Best answer: C
Explanation: In Scrum, accountability for ordering the Product Backlog and maximizing value belongs to the Product Owner. The Developers own the Sprint Backlog and adapt their plan as needed to achieve the Sprint Goal. The Scrum Master supports these interactions and coaches on Scrum, but does not make prioritization decisions or assign work.
The key decision is who is accountable for product ordering versus the plan for the Sprint. The Product Owner is accountable for maximizing value and for ordering the Product Backlog, so the compliance need should be discussed with the stakeholder and reflected in Product Backlog ordering. The Developers are accountable for creating the Increment and for managing the Sprint Backlog; they decide how to adjust the plan during the Sprint to pursue the Sprint Goal (and can collaborate with the Product Owner if scope changes are needed). The Scrum Master is accountable for the Scrum Team’s effectiveness and for coaching and facilitating, not for prioritizing product work or directing Developers.
The takeaway: prioritize through the Product Owner; plan changes through the Developers; enable through the Scrum Master.
Topic: Applying Scrum in Practice
Midway through a Sprint, the Scrum Team learns that a technical assumption behind several selected Product Backlog Items is wrong. The Sprint Goal is still valuable, but the team’s planned tasks and approach no longer make sense. The Developers decide to re-plan the remaining work for the Sprint and adjust what they will do next.
Which Scrum concept best matches this situation?
Best answer: D
Explanation: This situation is primarily about adapting the plan for delivering the Sprint Goal when new information invalidates part of the original plan. In Scrum, the Sprint Backlog is owned by the Developers and is expected to be updated throughout the Sprint as more is learned. Re-planning the remaining work is a normal use of the Sprint Backlog’s emergent nature.
When new information appears during a Sprint, Scrum expects the Scrum Team to adapt based on inspection and what is learned. If the Sprint Goal is still valid, the Developers adjust the Sprint Backlog (the selected work plus the plan for delivering it) to reflect the new reality. The Sprint Backlog is a living plan, and updating tasks, sequencing, and even renegotiating scope with the Product Owner is appropriate as long as the team continues to pursue the Sprint Goal and maintains transparency.
Cancellation is only relevant when the Sprint Goal becomes obsolete; otherwise, the team adapts its plan and continues the Sprint.
Topic: Applying Scrum in Practice
Midway through a Sprint, stakeholders frequently ask for “urgent” changes. The Developers propose adding a formal change-control process: a required change request form plus a weekly approval meeting before any new work can enter the Sprint.
As Scrum Master, what should you verify or ask first before deciding whether this added process is needed?
Best answer: B
Explanation: Before adding new controls, first inspect whether the Sprint Goal is clear and still achievable. In Scrum, changes during the Sprint are managed by negotiating scope as long as the Sprint Goal is not endangered. Using the Sprint Goal and Sprint Backlog decisions keeps the response lightweight and Scrum-aligned.
Adding a change-control board is typically a sign of trying to “manage” change with more process instead of using Scrum’s built-in mechanisms. First, inspect the Sprint Goal: if it is unclear or routinely being undermined, the team lacks a transparent basis for deciding what changes can be accepted.
Once the Sprint Goal is clear, the Scrum Team can use a simpler, Scrum-aligned approach:
This keeps adaptation fast and avoids adding approvals that reduce agility.
Topic: Applying Scrum in Practice
A Scrum Team’s stakeholders complain that “velocity is being gamed” and still don’t feel confident about delivery predictability or product quality. Leadership asks the Scrum Master to propose a small set of metrics that increases transparency of flow and quality.
Before recommending any metrics, what should the Scrum Master verify or ask FIRST?
Best answer: A
Explanation: To avoid gaming, metrics must be tied to a clear purpose: what question they should answer and what decisions they will inform. Clarifying the intended use and audience creates transparency and guides selecting complementary flow and quality measures. Without that, any metric can become a target and distort behavior.
In Scrum, evidence is used to support empiricism: transparency enables meaningful inspection and adaptation. Metrics are only useful when they are selected to answer a specific question (for example, “Are we improving flow to the Sprint Goal?” or “Is quality improving as reflected in Done outcomes?”) and when the people using the metric agree on how it will be interpreted. Starting by clarifying the decisions the metric will support helps you choose measures that reveal flow and quality (often as a balanced set) and reduces the risk of turning a single number into a target that drives gaming. Once the purpose is clear, you can then align candidate metrics with the Scrum Team’s context (Definition of Done, work item types, and how value is delivered) and inspect them over time.
Topic: Scrum Theory, Values, and Empiricism
A Scrum Team is building a new integration with an external partner. The work is highly uncertain, and the Product Owner suggests making the next Sprint 8 weeks long “so we can finish the whole integration before showing anything.”
As Scrum Master, what should you ask or verify FIRST before deciding how to proceed?
Best answer: B
Explanation: In uncertain work, risk is reduced by learning quickly through short timeboxes and frequent inspection. The first thing to clarify is what must be validated soonest and what minimal Done Increment can be produced to get meaningful feedback at the Sprint Review. That enables inspection and adaptation instead of delaying learning behind a longer Sprint.
Scrum reduces risk in uncertainty by timeboxing work into short Sprints and creating at least one Done Increment each Sprint to inspect with stakeholders and adapt based on what is learned. When someone proposes a longer Sprint “to finish everything,” the key missing information is what uncertainty drives the risk and how quickly the team can get evidence.
A good first step is to clarify:
This keeps the focus on empiricism (transparency via Done work, inspection at the Sprint Review, and adaptation of the Product Backlog) rather than extending the time to discover problems.
Topic: Scrum Theory, Values, and Empiricism
In Scrum, what is the intent of the three pillars of empiricism (transparency, inspection, and adaptation)?
Best answer: D
Explanation: Scrum uses empiricism to manage complexity through evidence-based decision making. Transparency makes the current state visible, inspection checks it regularly, and adaptation changes direction or approach when needed. Together they enable learning and timely adjustments toward desired outcomes.
The pillars of empiricism describe how Scrum supports learning in complex work. Transparency provides a shared understanding of the current state (for example, the Product Backlog, Sprint Backlog, and Increment are visible and understood). Inspection happens frequently enough to detect undesirable variances early (for example, during Scrum events). Adaptation is the adjustment made when inspection shows something is off-track or an improvement is possible, while minimizing further deviation. The intent is not to “lock in” requirements or rely on predictive control, but to make progress and decisions based on what is actually happening and then respond in time.
Topic: Artifacts, Commitments, and Done
A Scrum Team is preparing for the Sprint Review. The Sprint Backlog and Definition of Done (DoD) excerpt are below.
Sprint Backlog (excerpt)
PBI-101: Add "Reset password" UI - Done
PBI-102: Email service integration - In Review
PBI-103: Audit log export - Dev complete (tests pending)
DoD (excerpt)
- Code reviewed
- Automated tests passing
- Integrated on main branch
Based on the exhibit, what is the best interpretation of what can be considered the Increment for this Sprint?
Best answer: B
Explanation: An Increment is the sum of all Product Backlog Items completed during the Sprint (and previous Sprints) that is in usable condition and meets the Definition of Done. From the exhibit, only the item that satisfies the DoD criteria can be counted as part of the Increment. Items still in review or missing required tests are not Done and therefore are not part of the Increment.
In Scrum, the Increment is a concrete step toward the Product Goal that must be usable and meet the Definition of Done. “Done” is not a status label; it means the work satisfies the Scrum Team’s DoD, creating transparency about what quality and completeness are required.
From the exhibit, PBI-102 is still “In Review” and PBI-103 is missing “Automated tests passing,” so neither meets the DoD. Only PBIs that meet all DoD criteria (including integration) can be included in the Increment that is inspected at the Sprint Review. Work that is incomplete may be discussed, but it is not part of the Increment.
Key takeaway: the Increment contains only DoD-meeting work, regardless of how close other items are to completion.
Topic: Scrum Team and Accountabilities
A Scrum Team is halfway through a 10-day Sprint. The Scrum Master reviews the following Sprint information.
Sprint Goal: Enable customers to reset passwords
Day: 7/10
Board snapshot:
- PBI-21 Reset email UI: In Progress (3 Developers)
- PBI-22 Token service: In Progress (2 Developers)
- PBI-23 Audit log: To Do
- Done Increments: none
Daily Scrum notes: 25-30 minutes, each Developer reports status to Scrum Master
What is the best facilitation action for the Scrum Master to help make the next Daily Scrum more effective?
Best answer: A
Explanation: The exhibit shows the Daily Scrum has become a long status report to the Scrum Master and the Sprint has no Done Increment yet. The Scrum Master should help the Developers use the Daily Scrum as a 15-minute event to inspect progress toward the Sprint Goal and adapt the Sprint Backlog plan for the next 24 hours. This improves focus, transparency, and timely adaptation without changing Scrum.
A Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt their plan for the next day; it is not a status meeting to the Scrum Master. The exhibit shows warning signs: the event regularly exceeds 15 minutes, reporting is directed to the Scrum Master, and there is no Done Increment halfway through the Sprint. A Scrum Master’s facilitation is to reinforce the purpose and timebox and help the Developers collaborate on an actionable plan.
Practical facilitation moves include:
The key is enabling inspection and adaptation toward the Sprint Goal, not adding extra reporting or command-and-control.
Topic: Artifacts, Commitments, and Done
Halfway through a Sprint, the Developers run a quick usability test with real users and learn that a high-ordered upcoming feature in the Product Backlog will not deliver the expected value. The current Sprint Goal is still valid. What is the best Scrum-aligned way to evolve the Product Backlog based on this learning?
Best answer: D
Explanation: In Scrum, the Product Backlog is expected to evolve as more is learned about the product and its users. When new evidence changes what is most valuable, the Product Owner should immediately adapt the Product Backlog’s content and ordering so upcoming work reflects the latest understanding, while the current Sprint Goal can remain unchanged.
The Product Backlog is an emergent, ordered list of what is needed to improve the product, and it changes over time as the Scrum Team and stakeholders learn. When new information shows that a planned feature is less valuable (or unnecessary), Scrum favors adapting quickly: the Product Owner adjusts the Product Backlog by re-ordering items, removing or rewriting items, and adding new items as needed. This keeps the artifact transparent and ensures future Sprints focus on maximizing value toward the Product Goal. The current Sprint can continue when the Sprint Goal remains valid; learning primarily drives adaptation of what comes next via the Product Backlog, not by “freezing” plans or delaying updates.
Topic: Scrum Team and Accountabilities
True or False: If stakeholders are repeatedly surprised at the Sprint Review because the Increment is not what they expected, this indicates stakeholder expectations are unmanaged, and the Product Owner should strengthen ongoing stakeholder collaboration and transparency of the Product Goal and Product Backlog to better align expectations.
Best answer: A
Explanation: When stakeholders are consistently surprised at Sprint Review, expectations are not aligned with what the Scrum Team is building. In Scrum, the Product Owner is accountable for effective Product Backlog management and collaborating with stakeholders, using transparency to align on the Product Goal and upcoming work.
A recurring pattern of stakeholder surprise is a strong signal that expectations are not being actively managed and that transparency and feedback loops are not working well enough. In Scrum, the Product Owner is accountable for maximizing value and for effective Product Backlog management, which includes ensuring the Product Backlog is transparent, visible, and understood, and collaborating with stakeholders.
Practical alignment actions consistent with Scrum include:
The key takeaway is to improve collaboration and transparency to align expectations, rather than treating the surprise as simply a stakeholder problem.
Topic: Scrum Team and Accountabilities
During a Sprint, a new manager asks how the Scrum Team makes decisions day to day. Which statement about a self-managing Scrum Team is INCORRECT?
Best answer: C
Explanation: Self-managing means the Scrum Team internally decides how to accomplish its work without being directed by someone outside the team. The Developers own the plan for the Sprint and make day-to-day decisions to meet the Sprint Goal. The Product Owner and Scrum Master enable this through collaboration and coaching, not task assignment.
In Scrum, the Scrum Team is self-managing: they decide who does what, when, and how. In practice, this means the Developers create and adapt the Sprint Backlog plan throughout the Sprint and coordinate among themselves to meet the Sprint Goal. The Product Owner is accountable for maximizing value and can clarify and discuss Product Backlog Items, but does not manage Developers by assigning tasks. The Scrum Master serves the team by coaching, facilitating, and removing impediments, while supporting the team’s self-management rather than directing work. The key test is whether work decisions are made by the Scrum Team (especially the Developers for delivery) instead of being imposed by an external authority.
Topic: Scrum Events and Timeboxes
Statement: After the Daily Scrum, the Developers update the Sprint Backlog as needed to reflect their new plan for the next 24 hours and, if necessary, for the remainder of the Sprint.
Is this statement True or False?
Best answer: B
Explanation: The Daily Scrum results in an actionable plan created by the Developers to guide the next day of work toward the Sprint Goal. When new information emerges, they adapt by updating the Sprint Backlog to make the work and plan transparent. This replanning can affect the next 24 hours and can also trigger adjustments for the rest of the Sprint.
In Scrum, the Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The outcome is a shared, actionable plan that makes it clear how they will work together until the next Daily Scrum.
Updating the plan commonly includes:
The key point is that the Developers use what they learn in the Daily Scrum to replan and keep the Sprint Backlog current and transparent.
Topic: Scrum Theory, Values, and Empiricism
Midway through a Sprint, the Developers discover that one selected Product Backlog item is far larger than expected. If they continue as planned, they will likely miss the Sprint Goal. The Product Owner is available.
What is the most Scrum-aligned response?
Best answer: C
Explanation: During the Sprint, the Developers are expected to inspect progress and adapt their plan to meet the Sprint Goal. The Sprint Backlog is an actionable plan that can change as more is learned, and scope can be renegotiated with the Product Owner. The key is adapting the plan while preserving the Sprint Goal unless it becomes obsolete.
Scrum relies on empiricism: as new information emerges, the Scrum Team adapts. During a Sprint, the Developers own and continuously update the Sprint Backlog as a plan to achieve the Sprint Goal. If new understanding shows the current plan is unlikely to achieve the Sprint Goal, the appropriate move is to adapt the plan immediately and collaborate with the Product Owner to renegotiate scope (for example, splitting, swapping, or simplifying work) while still aiming at the same Sprint Goal.
The Sprint Goal provides focus and should not be changed casually; it only changes if it becomes obsolete, in which case the Product Owner may cancel the Sprint. The takeaway is to adapt the Sprint Backlog early and often to protect the Sprint Goal.
Topic: Scrum Theory, Values, and Empiricism
A Scrum Team notices feedback conversations often become defensive. The Scrum Master suggests a new approach: state the observable behavior, describe its impact on the team’s work, ask for the other person’s perspective, and focus on what to try next Sprint rather than blaming intent.
Which Scrum concept does this practice best reflect?
Best answer: C
Explanation: This feedback approach reduces defensiveness by separating people from problems and inviting shared understanding. That most directly reflects the Scrum value of Respect: team members assume positive intent, listen, and work together to improve. Respect enables honest inspection and practical adaptation without turning feedback into personal attacks.
In Scrum, learning and adaptation depend on a culture where people can give and receive feedback without fear or blame. The described behavior (observable facts, impact, inviting the other perspective, and proposing an experiment for the next Sprint) is a practical expression of the Scrum value Respect. Respect means recognizing one another as capable individuals and engaging professionally, which makes it safer to inspect how the team works and to adapt.
Openness and Courage can also support difficult conversations, but the key mechanism here is the non-blaming, person-respecting way the feedback is framed so the team can learn and change together.
Topic: Artifacts, Commitments, and Done
During Sprint Planning, the Product Owner presents three “Sprint Goals” to satisfy different stakeholders: (1) reduce onboarding time, (2) fix the top 10 production defects, and (3) deliver reporting v2. The Developers select work for all three and create a Sprint Backlog grouped under each goal. Mid-Sprint, the Daily Scrum becomes a negotiation about which goal to prioritize.
As Scrum Master, which TWO actions are most Scrum-aligned to correct this situation? (Select TWO)
Best answers: A, E
Explanation: A Sprint has one Sprint Goal that creates coherence for the Developers’ plan and guides day-to-day decisions. When multiple “goals” compete, the Scrum Team should re-establish a single Sprint Goal and align the Sprint Backlog to it. If necessary, move work that does not support that Sprint Goal back to the Product Backlog and continue the Sprint with clear focus.
In Scrum, the Sprint Goal is the single objective for the Sprint; it provides focus and a shared purpose for the Scrum Team. When multiple Sprint Goals are used, the Developers lose a coherent plan and the Daily Scrum turns into prioritization debates instead of inspecting progress toward one objective.
A Scrum-aligned correction is to re-establish one Sprint Goal and then adapt the Sprint Backlog accordingly. If the currently selected work represents distinct outcomes, the Scrum Team can de-scope by moving items back to the Product Backlog and continuing with a single Sprint Goal that best supports the Product Goal and near-term value. The key is one Sprint Goal, with scope flexibility handled through the Sprint Backlog and Product Backlog.
Topic: Scrum Team and Accountabilities
Mid-Sprint, a stakeholder asks the Developers to “skip the automated regression tests and code review so we can go faster” for an upcoming demo. The Scrum Team’s Definition of Done includes both steps.
What is the best Scrum-aligned response from the Developers?
Best answer: D
Explanation: The Definition of Done is a shared quality baseline for the Increment. If required quality steps are skipped, the work is not Done and transparency is reduced. Developers should uphold the Definition of Done and work with the Product Owner to adjust scope or expectations rather than trading off quality in secret.
In Scrum, Developers are accountable for creating a usable Increment that meets the Definition of Done each Sprint. When someone asks to “go faster” by skipping Definition of Done steps, the key issue is that this would produce work that is not Done, weakening transparency and increasing risk.
A Scrum-aligned response is to:
Speed comes from reducing scope or improving the system of work, not from lowering the agreed quality bar mid-Sprint.
Topic: Scrum Events and Timeboxes
In the last three Sprint Retrospectives, the Scrum Team spends most of the time venting about “constant changes” and “stakeholders interrupting us.” Little is said about the Increment, and the meeting ends with no concrete improvement experiment.
As the Scrum Master, what is the best clarifying question to ask FIRST before deciding how to adjust your facilitation?
Best answer: B
Explanation: A complaint-only Retrospective often lacks a shared focus on outcomes and learnings from the Sprint. Checking whether the Sprint Goal was clear and used during the Sprint restores transparency about what the team was trying to achieve and creates a basis for inspection and actionable adaptation. That insight informs how you should adjust facilitation to move from venting to improvement.
When a Retrospective turns into repeated complaining, the Scrum Master’s first move is to restore empiricism by anchoring the conversation in transparent Sprint outcomes. The Sprint Goal provides the key context for inspecting what happened and why: if it was unclear or not used to guide decisions, the team may default to frustration instead of learning.
A useful first check is whether the Sprint Goal was understood and actively used during the Sprint. From there, you can facilitate the team to inspect evidence (what helped or hindered meeting the goal) and agree on one or two actionable experiments for the next Sprint. If the goal was clear and still not met, the discussion can shift to specific impediments and collaboration patterns; if it wasn’t clear, improving Sprint Planning and goal alignment becomes a likely improvement focus.
Topic: Artifacts, Commitments, and Done
A Product Owner maintains a Product Backlog where every item is broken into tasks, assigned to specific Developers, and given target dates for the next three months. In Sprint Planning, the Product Owner tells the team to “follow the backlog as our project plan.” The Scrum Team has a clear Definition of Done, uses Sprint Goals, and routinely produces a Done Increment.
What is the most likely underlying cause in Scrum terms?
Best answer: B
Explanation: The key symptom is the Product Backlog being treated as a fixed, task-level schedule with assignments and dates. In Scrum, the Product Backlog is an emergent, ordered list of what is needed to improve the product, while the Developers create the Sprint plan in the Sprint Backlog. This points to a misunderstanding of accountabilities and the purpose of the Product Backlog.
A Product Backlog is not a project plan or a commitment to deliver a pre-defined scope by specific dates. It is an emergent, ordered list of work needed to achieve the Product Goal, and it changes as more is learned.
In the scenario, Sprint Goals and a strong Definition of Done already exist and Done Increments are produced, so the issue is not “lack of Scrum events” or “quality control.” The underlying problem is that the Product Owner is acting like a project manager by assigning tasks and scheduling detailed work months ahead, rather than ordering Product Backlog items by value and collaborating with Developers to make items clear and ready for selection.
The Sprint Backlog is the Developers’ plan for the Sprint; the Product Backlog supports forecasting, not fixed scheduling.
Topic: Scrum Theory, Values, and Empiricism
A Scrum Team is building a new internal HR portal. Stakeholders have asked for regular opportunities to give feedback, but the Product Owner plans to gather feedback only after a “final UAT phase” at the end of the 6-month effort. The Developers typically integrate work late and say early reviews would be “too unfinished to show.”
Which TWO actions best address that adaptation is too slow in a Scrum-aligned way? (Select TWO)
Best answers: A, E
Explanation: In Scrum, adaptation should happen frequently using empirical feedback, not at the end of a project. The Sprint Review is the primary event for stakeholders to inspect the Increment and influence what to do next. Producing a Done, usable Increment each Sprint makes it practical to validate and release sooner, enabling timely adaptation.
Waiting until a “final UAT phase” delays inspection and adaptation, increasing the risk of building the wrong thing and making change expensive. Scrum addresses this by creating opportunities every Sprint to inspect results and adapt plans.
Effective, Scrum-aligned remedies here are:
The key takeaway is to shorten the feedback loop using Scrum’s events and a Done Increment, rather than deferring learning to the end.
Topic: Scrum Team and Accountabilities
Midway through a Sprint, the Developers discover that a Product Backlog item they selected is much larger than expected. In the Daily Scrum they have been reporting “percent complete” and leaving the Sprint Backlog unchanged, so the Product Owner still believes the Sprint is on track.
What is the best action the Developers can take now?
Best answer: A
Explanation: When Developers discover work is larger than expected, they adapt their plan for the Sprint. The Sprint Backlog should be updated to make the new work visible and to re-plan how the team will achieve the Sprint Goal, involving the Product Owner when trade-offs to scope or the Sprint Goal are needed.
In Scrum, Developers are accountable for managing the Sprint Backlog and adapting their plan each day toward the Sprint Goal. When new information shows work is larger than expected, the right response is to increase transparency (update the Sprint Backlog with the newly discovered work, remaining effort, and changed approach) and then adapt. If the Developers believe the Sprint Goal is at risk, they collaborate with the Product Owner to negotiate scope and options while keeping the Sprint Goal as the focus.
This keeps inspection and adaptation happening in time to influence outcomes, rather than hiding surprises until the end of the Sprint. The key is to change the plan, not the quality bar.
Topic: Scrum Theory, Values, and Empiricism
A Scrum Team has reached the end of the Sprint with a Done Increment. Several stakeholders want to see what was built and discuss what to do next because market conditions have changed.
Which Scrum event best fits this situation, and what is its main inspection/adaptation purpose?
Best answer: A
Explanation: At the end of the Sprint, the Scrum Team and stakeholders inspect what was actually delivered: the Done Increment. The purpose of the Sprint Review is to use that inspection and current conditions to collaborate on next steps and adapt the Product Backlog accordingly.
Each Scrum event is designed to enable empiricism by creating a regular opportunity to inspect something specific and adapt based on what is learned. In this scenario, the key discriminator is that stakeholders want to review the newly completed Done Increment and adjust future direction due to changed market conditions.
The Sprint Review is the event focused on:
The other events inspect different things: the Sprint Retrospective inspects how the team worked, the Daily Scrum inspects progress toward the Sprint Goal, and Sprint Planning creates the Sprint Goal and plan for the upcoming Sprint.