Try 80 free PSM I questions across the exam domains, with answers and explanations, then continue in PM Mastery.
This free full-length PSM I practice exam includes 80 original PM Mastery questions across the exam domains.
The questions are original PM Mastery practice questions aligned to the exam outline. They are not official exam questions and are not copied from any exam sponsor.
Official-count note: Scrum.org currently lists PSM I as 80 questions in 60 minutes with an 85% passing score. Use Scrum.org for final exam-day rules; use this page as an original full-length PM Mastery diagnostic.
For concept review before or after this set, use the PSM I guide on PMExams.com.
Set a 60-minute timer and answer all 80 questions in one sitting. Use the answer explanation only after you commit to an answer, then mark each miss by the Scrum concept you confused: accountabilities, events, artifacts, commitments, empiricism, or applied Scrum behavior.
Suggested timing checkpoints:
| Question range | Target elapsed time |
|---|---|
| 1-25 | 19 minutes |
| 26-55 | 41 minutes |
| 56-80 | 60 minutes |
| Item | Detail |
|---|---|
| Issuer | Scrum.org |
| Exam route | PSM I |
| Official exam name | Scrum.org Professional Scrum Master I (PSM I) |
| Full-length set on this page | 80 questions |
| Exam time | 60 minutes |
| Topic areas represented | 5 |
| Topic | Approximate official weight | Questions used |
|---|---|---|
| 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 |
Topic: Scrum Team and Accountabilities
A Scrum Team is building an internal HR self-service product. The HR director and a legal counsel frequently give feedback and sometimes ask Developers to add urgent changes mid-Sprint.
Select TWO statements that are correct about stakeholders in Scrum.
Correct answers: B, F
What this tests: Scrum Team and Accountabilities
Explanation: Stakeholders are people outside the Scrum Team who can influence or be impacted by the product and its outcomes. The Product Owner is accountable for engaging stakeholders and representing their interests through Product Backlog management to maximize value. Stakeholders can provide input, but they do not manage the Sprint Backlog or direct the Developers’ work.
In Scrum, stakeholders are anyone outside the Scrum Team who can affect or be affected by the product, such as users, customers, sponsors, internal departments, regulators, or support groups. In this scenario, the HR director and legal counsel are stakeholders because they have an interest in the product’s outcomes and can influence what is valuable or necessary.
The Product Owner is accountable for maximizing value and therefore for effective stakeholder collaboration. Practically, that means:
Stakeholders may participate in events like the Sprint Review to inspect the Increment and provide feedback, but they do not control the Scrum Team’s work within the Sprint.
They are outside the Scrum Team and can affect or be affected by the product.
The Product Owner represents stakeholder needs by managing and ordering the Product Backlog to maximize value.
Topic: Scrum Team and Accountabilities
A Scrum Team is in the middle of a Sprint and progress has slowed. The Scrum Master reviews the Sprint Backlog.
Sprint Goal: Enable self-serve trial sign-up
PBI-21 Add email verification (Planned)
PBI-34 Add form validations (Planned)
STK-7 Change "Start Free Trial" to "Request a Demo" (Added: Sales)
STK-8 Keep "Free Trial" but remove credit card field (Added: Marketing)
Note: Developers are switching direction based on stakeholder messages.
What is the best facilitation response by the Scrum Master?
Best answer: A
What this tests: Scrum Team and Accountabilities
Explanation: The exhibit shows conflicting stakeholder requests pulling the Developers in different directions and harming progress toward the Sprint Goal. The Scrum Master should facilitate transparency and a focused conversation so the Product Owner and Developers can inspect the situation and adapt the Sprint Backlog appropriately. This restores alignment and reduces thrashing without adding non-Scrum controls.
Conflicting stakeholder demands are harming outcomes when they create thrashing, reduce transparency, and prevent the Scrum Team from making coherent progress toward the Sprint Goal. The Scrum Master’s facilitation response is to help the right people collaborate: make the conflict visible, enable constructive dialogue, and support an inspect-and-adapt decision.
In this case, facilitate a conversation among the Product Owner, Developers, and the relevant stakeholders to:
The key takeaway is to remove the destructive conflict through facilitation and alignment, not by creating gatekeeping or heavy change-control mechanisms.
This addresses the stakeholder conflict by enabling transparency and a shared decision with the Product Owner and Developers about what to do next.
Topic: Artifacts, Commitments, and Done
A Scrum Team has a Definition of Done that includes code review and unit tests. Over the last few Sprints, Product Backlog Items were marked Done and included in the Increment, but stakeholders reported quality problems after release.
Which TWO observations are the best reasons to adapt the Definition of Done?
Correct answers: C, E
What this tests: Artifacts, Commitments, and Done
Explanation: The Definition of Done is adapted when inspection shows it is not sufficient to ensure a usable, potentially releasable Increment. Repeated defects escaping after work is considered Done, or frequent “hardening” work pushed to later Sprints, are strong signals that the DoD needs to be improved to raise transparency and quality.
The Definition of Done makes the level of quality and completeness transparent for the Increment. When quality issues are repeatedly discovered after items are considered Done, that is an empiricism signal that the current DoD is not effectively ensuring a usable Increment and should be adapted. Typical triggers include recurring escaped defects (for example, integration or performance problems) and patterns of rework where “Done” items still need additional testing, stabilization, or other quality activities in a later Sprint.
Adapting the DoD means making quality expectations explicit and consistent for all work included in the Increment (for example, adding necessary integration testing or other verifications). If problems come from not following the existing DoD, the right response is to improve adherence and transparency, not to change the standard of “Done.”
Recurring defects escaping a “Done” Increment indicate the DoD is insufficient to ensure the needed quality.
If completed items frequently require extra quality work later, the DoD should be strengthened to prevent rework.
Topic: Applying Scrum in Practice
Midway through a Sprint, the Developers discover that a critical integration task will take much longer than expected. If they continue as planned, they will likely miss the Sprint Goal. The Sprint Goal is still valuable and achievable if some lower-value Product Backlog Items are removed from the Sprint.
What is the best next step?
Best answer: B
What this tests: Applying Scrum in Practice
Explanation: When new information emerges during a Sprint, the Developers inspect progress and adapt the Sprint Backlog. Because the Sprint Goal remains valuable, the right move is to collaborate with the Product Owner to renegotiate scope and adjust tasks so the Sprint Goal can still be met within the timebox.
In Scrum, the Sprint Goal provides focus and should remain stable during the Sprint. When work turns out differently than expected, the Scrum Team applies empiricism by inspecting progress and adapting the plan. The Developers own the Sprint Backlog and can adjust tasks and their plan daily, but if meeting the Sprint Goal requires changing the scope of selected Product Backlog Items, that scope is clarified and renegotiated with the Product Owner.
A practical sequence is:
Only if the Sprint Goal becomes obsolete would cancellation be considered.
Sprint scope can be renegotiated with the Product Owner during the Sprint so the Developers can adapt their plan while preserving the Sprint Goal.
Topic: Scrum Team and Accountabilities
A Product Owner asks a business analyst to make all Product Backlog ordering decisions and to communicate priorities to the Developers, because the Product Owner wants to focus only on stakeholder management. According to Scrum, which statement is correct?
Best answer: A
What this tests: Scrum Team and Accountabilities
Explanation: The Product Owner is accountable for maximizing value and for effective Product Backlog management, including ordering. While the Product Owner can delegate tasks (analysis, drafting, facilitating discussions), they cannot delegate away accountability. They must remain the final decision-maker for Product Backlog ordering.
In Scrum, accountability is not something the Scrum Team can “hand off” to another role or person. The Product Owner is accountable for maximizing the value of the product and for effective Product Backlog management, which includes ordering Product Backlog items. The Product Owner may ask others (e.g., a business analyst, stakeholders, or Developers) to help with discovery, analysis, and proposing an order, but the Product Owner remains accountable for the decisions and outcomes. If ordering decisions are being made outside the Product Owner’s accountability, transparency and clear decision ownership are reduced, making it harder to inspect and adapt toward the Product Goal. The key correction is to keep delegation as support, not as a transfer of accountability.
In Scrum, the Product Owner can ask others to help, but accountability for Product Backlog ordering and value decisions stays with the Product Owner.
Topic: Scrum Events and Timeboxes
A Scrum Team is three days from the end of a 2-week Sprint. Several Product Backlog Items selected in Sprint Planning are not likely to be finished. The Product Owner asks to extend the Sprint “so we can deliver everything we planned.”
During Sprint Planning, the Sprint Goal was written as: “Complete all committed items from the Sprint Backlog.” The Developers say they cannot decide what to drop or renegotiate because “everything is equally important.” The team’s Definition of Done is clear and at least one Increment has already met it this Sprint.
What is the most likely underlying cause, in Scrum terms, behind the pressure to extend the Sprint?
Best answer: C
What this tests: Scrum Events and Timeboxes
Explanation: Extending a Sprint to “finish everything” is commonly driven by a Sprint Goal that provides no meaningful objective beyond completing a list. Without a clear, valuable Sprint Goal, the team lacks a basis to adapt scope while keeping the timebox fixed. The clues show DoD is clear and at least one Done Increment exists, so the issue is focus rather than quality or visibility.
In Scrum, the Sprint is a fixed timebox; when work is unfinished, the typical adaptation is to renegotiate scope while still meeting the Sprint Goal (or learn that the Sprint Goal was not met). A Sprint Goal should create focus and enable trade-offs.
Here, the “Sprint Goal” is essentially a promise to complete all selected work. That does not express a coherent objective or value, so when reality differs from the plan, the team has no decision rule for what to keep, drop, or re-order—leading to pressure to extend the Sprint to match the original plan.
A clear Definition of Done and visible progress support empiricism, but they cannot replace a meaningful Sprint Goal.
A Sprint Goal that simply restates a commitment to finish all items provides no focus, so unfinished work leads to extending the timebox instead of renegotiating scope.
Topic: Scrum Events and Timeboxes
A Scrum Team finishes each Sprint with a Done Increment and a clear Sprint Goal that is usually met. However, their Sprint Review is a 15-minute demo led by the Product Owner, stakeholders rarely attend, and there is no discussion of what to do next. A week later, stakeholders send new requests by email and the Product Backlog is changed without shared conversation.
What is the most likely underlying cause in Scrum terms?
Best answer: C
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Review’s purpose is to inspect the outcome of the Sprint with stakeholders and collaborate on what to do next, adapting the Product Backlog accordingly. The clues show the team produces a Done Increment and has clear goals, but the Review lacks stakeholder participation and meaningful conversation, so inspection and adaptation happen later and asynchronously.
In Scrum, the Sprint Review is a working session to inspect the Increment and the progress toward the Product Goal with key stakeholders, then adapt the Product Backlog based on what was learned. In the scenario, the team has a Done Increment and a clear Sprint Goal, yet the event is reduced to a short demo with little stakeholder engagement and no “what now” collaboration. That removes timely transparency and inspection, so feedback arrives later via email and backlog changes occur without shared understanding. The root cause is misuse of the Sprint Review, not the quality of the Increment or the clarity of the Sprint Goal.
Without a collaborative inspection of the Increment with stakeholders, the Product Backlog is not adapted based on feedback and new information.
Topic: Scrum Team and Accountabilities
Two stakeholders disagree about what should be built next: one wants a compliance report, the other wants a new onboarding flow. To “stay neutral,” the Product Owner re-orders the Product Backlog using first-come, first-served and does not explain how this supports the Product Goal.
What is the most likely near-term impact?
Best answer: A
What this tests: Scrum Team and Accountabilities
Explanation: The Product Owner orders the Product Backlog to maximize value toward the Product Goal and should make the rationale transparent. Using first-come, first-served to avoid disagreement hides the “why” behind priorities. That lack of transparency quickly shows up in Sprint Planning as difficulty forming a meaningful Sprint Goal and selecting the most valuable work.
When stakeholders disagree, the Product Owner remains the single point of accountability for ordering the Product Backlog. The ordering should reflect what best maximizes value and progress toward the Product Goal (often factoring value, risk, dependencies, and learning), and the rationale should be made transparent.
If the Product Backlog is ordered “neutrally” (for example, first-come, first-served) without explaining how items support the Product Goal, the team and stakeholders lose clarity on priorities. The most immediate consequence is friction in Sprint Planning: it becomes harder to negotiate a coherent Sprint Goal and to choose work that best advances the product.
Longer-term effects like trust erosion can happen, but the near-term impact is reduced transparency and alignment.
Ordering without a Product Goal/value rationale reduces transparency and makes selecting work for a coherent Sprint Goal harder.
Topic: Scrum Events and Timeboxes
During a Sprint, the Developers hold a 15-minute Daily Scrum. The Product Owner asks to attend every day “to clarify scope,” and a stakeholder asks to join “for daily status.” The Scrum Master is unsure what to allow.
Select TWO statements that are consistent with Scrum.
Correct answers: A, D
What this tests: Scrum Events and Timeboxes
Explanation: The Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt their plan. Therefore, Developers are the only required attendees. The Scrum Master (and others) are not required, but may attend when helpful and when it does not undermine the Developers’ ownership of the event.
In Scrum, the Daily Scrum is explicitly an event for the Developers. Its purpose is for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog (their plan for the next day of work). Because of that purpose, Developers are the only people who must attend.
Other people (including the Scrum Master, Product Owner, or stakeholders) are not required attendees. They may be present only in a way that supports the Developers and does not turn the event into a status meeting or reduce transparency and self-management. The Scrum Master’s accountability is to ensure Scrum events occur and are effective, but the Developers conduct the Daily Scrum.
The Daily Scrum is an event for the Developers, so only they are required participants.
The Scrum Master ensures the event happens and may observe/coach, but it remains for and run by the Developers.
Topic: Artifacts, Commitments, and Done
A Product Owner shares a Product Backlog that includes fixed delivery dates and team member assignments for the next 6 months. Stakeholders are treating it as a committed project plan and are escalating whenever new items appear.
As Scrum Master, what is the best Scrum-aligned response?
Best answer: B
What this tests: Artifacts, Commitments, and Done
Explanation: A Product Backlog is not a project plan; it is an emergent, ordered list that changes as more is learned. The Scrum Master should help the Product Owner and stakeholders restore transparency by using the Product Goal and making clear that only Sprint-level work is planned in detail. Longer-term expectations can be managed through ordering and forecasting, not fixed commitments in the Product Backlog.
In Scrum, the Product Backlog is the single source of work for the Scrum Team and is an emergent artifact that evolves based on learning, feedback, and changes in context. Treating it as a fixed, date-based project plan undermines empiricism and creates false commitments.
A Scrum-aligned correction is to help the Product Owner:
The key takeaway is to re-establish the Product Backlog as a flexible ordering tool for value, not a contractual schedule.
The Product Backlog is a continuously evolving, ordered list owned by the Product Owner, so dates/assignments should not be treated as commitments; use the Product Goal and forecasting to align expectations.
Topic: Artifacts, Commitments, and Done
A Scrum Team is working on a product with the Product Goal: “Customers can change their shipping address without contacting support, reducing address-change support tickets by 30%.”
At the end of the Sprint, which TWO pieces of evidence best indicate progress toward the Product Goal? (Select TWO)
Correct answers: B, F
What this tests: Artifacts, Commitments, and Done
Explanation: Progress toward a Product Goal is best evidenced by inspectable outcomes: a Done Increment that can be used and the resulting product/market measures that reflect the goal’s intent. Output-only signals (tasks completed, velocity, tool statuses) can be misleading without a usable Increment and evidence of the desired outcome.
In Scrum, the Product Goal is a long-term objective described in the Product Backlog, and progress is inspected through transparency around what was actually achieved and what impact it has. The most direct evidence is a usable, Done Increment because it is concrete and inspectable, not just activity. When the Product Goal is expressed as an outcome (for example, fewer support tickets), empirical product data after releasing and using the Increment is also strong evidence of progress.
Measures like tasks completed, velocity changes, or items marked “done” in a tool are secondary at best because they can increase without producing a Done Increment or without moving the outcome the Product Goal describes. The key takeaway is to prefer evidence tied to a Done Increment and observable results aligned to the Product Goal.
A usable Increment that meets the Definition of Done provides concrete evidence of product progress toward the Product Goal.
A measured reduction in the targeted support tickets directly evidences movement toward the Product Goal outcome.
Topic: Scrum Events and Timeboxes
A Scrum Team claims their Sprint Review went well, but the only attendees were the Developers and Scrum Master, and they presented slides about “percent complete.” The Product Owner wants a clear indicator that the Sprint Review is being used as intended and that stakeholders are playing their proper role.
Which option is the best evidence that validates this?
Best answer: A
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Review is a working session where the Scrum Team and stakeholders inspect the Done Increment and collaborate on what to do next. Stakeholders participate by providing feedback and insights to adapt the Product Backlog toward the Product Goal. Evidence centered on inspection of the Increment and stakeholder feedback best validates progress and value.
In Scrum, the Sprint Review’s purpose is to inspect the outcome of the Sprint and determine future adaptations. Participants include the Scrum Team and the stakeholders invited by the Product Owner. The most meaningful validation is grounded in empiricism: a Done Increment is inspected, stakeholders provide feedback and context (market, customers, usage), and the Product Owner uses that collaboration to adapt the Product Backlog and likely update forecasting.
Measures or artifacts that bypass stakeholder collaboration (reports) or focus on internal progress signals (charts) do not show the Sprint Review is fulfilling its intent. The key takeaway is that stakeholders help validate value by inspecting the Increment and collaborating on next steps, not by formally approving work.
The Sprint Review validates value by having the Scrum Team and stakeholders inspect the Increment and collaborate on feedback.
Topic: Artifacts, Commitments, and Done
A Scrum Team is building a mobile banking app. At the Sprint Review, stakeholders inspect the latest Increment and report that a recently announced regulation will require different capabilities sooner than expected. During the next week, the Product Owner inspects production telemetry from earlier Increments and sees that a released feature is rarely used and users abandon the flow.
Which TWO actions reflect when the Product Backlog should be adapted based on these inspection results? (Select TWO)
Correct answers: A, F
What this tests: Artifacts, Commitments, and Done
Explanation: The Product Backlog is an emergent artifact and should be adapted whenever inspection reveals new information about value, risk, or what is needed. Sprint Review feedback is a key inspection point for adjusting ordering. Inspection of actual product outcomes (such as telemetry) can also drive immediate Product Backlog updates by the Product Owner.
In Scrum, inspection results should lead to timely adaptation to maximize value. The Product Backlog is continuously refined and can be updated at any time; it is not limited to a specific event or “change window.” When stakeholders inspect the Increment at the Sprint Review and new constraints or opportunities emerge, the Product Owner adapts the Product Backlog (often by re-ordering items or adding new ones). Likewise, inspecting real usage and outcomes between events can reveal that assumptions were wrong or needs changed, and the Product Backlog should be updated promptly.
Key takeaway: adapt the Product Backlog whenever inspection provides new, actionable learning; don’t wait for a single ceremony or delegate Product Backlog ordering to others.
Sprint Review inspection can change what is most valuable, so the Product Backlog ordering should be adapted.
Ongoing inspection of outcomes can reveal new work or changed priorities, prompting Product Backlog adaptation.
Topic: Applying Scrum in Practice
The Sprint ends tomorrow. The Developers say the current Increment is “Done,” but the Product Owner is concerned because some integration and regression testing is usually done late. The Product Owner asks for evidence that the Increment is truly Done.
What is the best next step?
Best answer: A
What this tests: Applying Scrum in Practice
Explanation: “Done” is evidenced by the Increment meeting the Scrum Team’s Definition of Done. The best next step is to inspect the Increment against that shared standard (using objective checks such as test results or integration status) to confirm the work is complete and usable. This creates transparency and supports inspection and adaptation.
In Scrum, “Done” is not a subjective claim or a proxy metric; it is a state defined by the Scrum Team’s Definition of Done (DoD), the commitment for the Increment. When there is uncertainty, the most appropriate evidence is to inspect the Increment and verify it meets every DoD criterion (for example: integrated, tested, documented as required, and usable).
A practical next step is:
This keeps “Done” transparent and avoids adding extra gates or relying on misleading progress measures.
The Definition of Done is the standard for “Done,” so checking the Increment against it provides objective evidence.
Topic: Applying Scrum in Practice
A company has two-week Sprints and multiple Scrum Teams working on the same product. The teams report they rarely finish anything “Done” within a Sprint.
Exhibit: Definition of Done (organizational standard)
- Code reviewed and all tests pass
- Deployed to production
- CAB approval recorded (CAB meets monthly)
Based on the exhibit, what is the best Scrum-aligned change to address the conflict with empiricism?
Best answer: D
What this tests: Applying Scrum in Practice
Explanation: Empiricism depends on frequent transparency and inspection of a Done Increment. A monthly CAB approval that is embedded in the Definition of Done prevents most Sprints from producing a Done Increment, reducing timely feedback and adaptation. The Scrum-aligned response is to make this impediment transparent and work with the organization to change the policy so release approval can happen within a Sprint.
A Scrum Team should be able to create a Done, usable Increment every Sprint so stakeholders can inspect progress toward the Product Goal and adapt the Product Backlog. The exhibit shows an organizational policy (monthly CAB approval tied to production deployment) baked into the Definition of Done, which makes “Done” impossible in most two-week Sprints.
A Scrum-aligned change is to treat this as an organizational impediment and collaborate with leaders/CAB to evolve the policy to support empiricism, for example by enabling more frequent approvals, delegating approval, or automating controls so approval/deployment can be completed within the Sprint when needed. This preserves quality/compliance while restoring frequent transparency, inspection, and adaptation.
A monthly CAB gate blocks frequent transparency and inspection of a Done Increment, so the organization should adapt its policy to enable at least one Done Increment each Sprint.
Topic: Scrum Theory, Values, and Empiricism
A Scrum Team realizes stakeholders are drawing different conclusions about progress because work items and quality expectations are unclear. The Developers update the Sprint Backlog so it is visible and understandable, and they make sure everyone shares the same Definition of Done and acceptance criteria.
Which Scrum concept best matches the intent of this practice?
Best answer: C
What this tests: Scrum Theory, Values, and Empiricism
Explanation: This practice is about making the state of the work and the quality bar clear to everyone. That is the pillar of transparency: ensuring significant aspects of the process and work are visible and shared. Without transparency, inspection and adaptation are based on misleading information.
Empiricism in Scrum relies on three pillars: transparency, inspection, and adaptation. The described actions focus on making the Sprint Backlog, acceptance criteria, and the Definition of Done visible and commonly understood. That directly supports transparency, whose intent is to create a shared understanding of the current state so that any inspection is trustworthy.
When transparency is improved:
Inspection and adaptation may follow, but the primary intent in the scenario is to increase transparency.
It makes the work and quality standards visible and commonly understood so inspection can be meaningful.
Topic: Scrum Events and Timeboxes
During Sprint Reviews, a stakeholder group requires a formal “approval” document before work can be considered complete. The Scrum Team wants to correct this sign-off gate behavior while still providing clear validation of progress, quality, and value.
Which is the best evidence/indicator to use in the Sprint Review?
Best answer: A
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Review is for inspecting the outcome of the Sprint and adapting the Product Backlog based on what was learned. The most credible validation is a Done Increment, because it is usable and meets the Definition of Done, allowing stakeholders to inspect real product results and provide feedback without turning the event into a phase-gate approval.
Treating the Sprint Review as a sign-off gate shifts focus from empiricism to document-based approval and can delay learning and value delivery. In Scrum, progress and quality are validated by the Scrum Team delivering a Done Increment each Sprint. Bringing that Increment to the Sprint Review enables transparency (what is actually usable), inspection (stakeholders experience the product), and adaptation (changes to the Product Backlog based on feedback and current conditions).
The key correction is to make the Sprint Review about inspecting the Done Increment and discussing next valuable steps toward the Product Goal, rather than requiring a formal approval artifact before acknowledging completion.
A Done Increment is the primary evidence of usable progress and enables inspection and feedback without a sign-off gate.
Topic: Scrum Events and Timeboxes
A Scrum Team runs 2-week Sprints. Their Sprint Reviews have become “demo theater”: Developers present a scripted slide deck and a few mockups, stakeholders have little time to ask questions, and the Product Owner usually updates the Product Backlog later without changing priorities.
This Sprint, the Sprint Goal was “Enable users to export reports,” and only the features that meet the Definition of Done are potentially releasable. Stakeholders need to decide whether export should support PDF or CSV first.
What is the BEST next action for the Scrum Master?
Best answer: A
What this tests: Scrum Events and Timeboxes
Explanation: A Sprint Review is a working session to inspect the current Increment (only what is Done) and collaborate with stakeholders to adapt the Product Backlog. In this case, stakeholders need an informed decision (PDF vs CSV), which is best achieved by inspecting the Done export capability and discussing next steps in the Review. The Scrum Master should correct the “demo theater” pattern by enabling transparency, interaction, and immediate adaptation.
The Sprint Review’s purpose is to inspect the outcome of the Sprint and determine future adaptations with stakeholders. A scripted presentation that limits questions reduces transparency and inspection, and deferring decisions and backlog changes removes adaptation.
The Scrum Master should help the Scrum Team run the Review as a collaborative working session:
The key correction is shifting from “performing a demo” to enabling inspection and adaptation based on the real Increment.
The Sprint Review exists to inspect the Increment and collaboratively adapt the Product Backlog using stakeholder feedback, not to run a scripted demo.
Topic: Scrum Theory, Values, and Empiricism
Midway through a Sprint, stakeholders ask to see progress toward the Sprint Goal. The Developers explain that they are working in phases: “this Sprint is analysis and design; coding starts next Sprint; testing and integration will happen in a later Sprint.” They expect no Product Backlog Item to meet the Definition of Done until those later Sprints.
What is the best correction for the Scrum Master to coach to improve near-term transparency and Sprint Goal progress?
Best answer: D
What this tests: Scrum Theory, Values, and Empiricism
Explanation: The team is treating Sprints as sequential project phases, which delays a Done Increment and hides real progress and quality issues. Coaching vertical slicing and completing work to the Definition of Done within the Sprint restores transparency and enables meaningful inspection at the Sprint Review. This also makes Sprint Goal progress visible day by day.
This is a “waterfall-in-sprints” anti-pattern: analysis, coding, and testing are separated into different Sprints (or large phases), so there is no Done Increment to inspect. The fastest correction is to change how work is selected and planned so that each Sprint contains end-to-end Product Backlog Items that can meet the Definition of Done, enabling real progress toward the Sprint Goal and early discovery of quality/integration problems.
Practical coaching moves include:
Creating a Done Increment each Sprint is the key lever; delaying integration/testing pushes inspection and adaptation too late.
Vertical slicing and integrating testing/design into the Sprint enables a Done Increment and transparent progress toward the Sprint Goal each Sprint.
Topic: Scrum Events and Timeboxes
A Scrum Team begins a Sprint with a detailed task list but no clear objective to guide trade-offs. Which Scrum term describes the missing commitment that should be created during Sprint Planning to provide focus for the Sprint?
Best answer: C
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Goal is the Scrum Team’s single objective for the Sprint and is created during Sprint Planning. It provides focus and helps the Developers and Product Owner make trade-offs as they discover work and adapt the Sprint Backlog. Starting Sprint work without it risks optimizing for task completion rather than achieving a coherent Sprint outcome.
In Scrum, the Sprint Goal is the commitment for the Sprint Backlog and answers why the Sprint is valuable. It is created during Sprint Planning and gives the Scrum Team a shared objective that enables self-management and empiricism: the team can inspect progress toward the goal and adapt the Sprint Backlog while keeping a clear purpose.
If work starts without a clear Sprint Goal, the correction is for the Scrum Team to establish (or clarify) a Sprint Goal aligned with the Product Goal and then adjust the Sprint Backlog accordingly. This is different from quality constraints (Definition of Done) or item-level detail (acceptance criteria).
The Sprint Goal is the commitment for the Sprint Backlog and provides a single objective that guides the team’s work and decisions during the Sprint.
Topic: Artifacts, Commitments, and Done
A Scrum Team is in a 2-week Sprint with 2 days remaining. The Sprint Goal is “Customers can reset their password,” and a key stakeholder expects to see usable functionality at the Sprint Review.
The team’s Definition of Done is currently “code committed and peer reviewed.” In recent Sprints, work that met this Definition of Done repeatedly required significant rework after the Sprint because basic integration and security issues were found later. This Sprint, several Product Backlog Items appear “done” but still fail basic end-to-end testing.
What is the BEST next action?
Best answer: A
What this tests: Artifacts, Commitments, and Done
Explanation: The Definition of Done creates transparency about what “complete” means, and only work that meets it can be part of a Done Increment. If quality problems are causing rework, the Scrum Team should keep incomplete work visible, adapt the plan with the Product Owner to still pursue the Sprint Goal, and improve the Definition of Done as a concrete outcome of the Sprint Retrospective.
A weak Definition of Done undermines transparency and leads to predictable rework because “done” does not reflect the quality needed for a usable Increment. In Scrum, the Definition of Done is a shared commitment for the Increment and is owned by the Scrum Team; it cannot be bypassed to satisfy a date, and the Sprint timebox is fixed.
In this situation, the team should:
The key takeaway is to improve quality by strengthening the Definition of Done, not by extending the Sprint or redefining “done” to hide unfinished work.
A weak Definition of Done must be improved by the Scrum Team while keeping incomplete work transparent and delivering only a Done Increment within the Sprint timebox.
Topic: Scrum Team and Accountabilities
Midway through a Sprint, a key stakeholder asks the Developers to add a new regulatory requirement that was not discussed in Sprint Planning. The Product Owner is unexpectedly unreachable for the next three business days, and no one has been asked to make Product Backlog decisions in their absence.
What is the most Scrum-aligned action to mitigate the Product Owner’s absence and its near-term impact on transparency and Sprint Goal progress?
Best answer: A
What this tests: Scrum Team and Accountabilities
Explanation: Only the Product Owner is accountable for ordering the Product Backlog and maximizing value, so their absence primarily threatens transparent decision-making about what to do next. The best near-term mitigation is to keep work aligned to the Sprint Goal using the current Sprint Backlog, while making the new request and its impact transparent so it can be decided as soon as the Product Owner is available.
A missing Product Owner creates an immediate risk that value decisions (what to build next, and whether to change direction) become implicit or are made by others without clear accountability. In Scrum, the Developers can self-manage their plan for achieving the Sprint Goal, but product decisions and Product Backlog ordering remain with the Product Owner.
A Scrum-aligned mitigation is to:
This reduces thrash and preserves transparency without inventing new roles or bypassing the Product Owner’s accountability.
It preserves focus on the Sprint Goal and transparency while ensuring Product Backlog changes are decided when the Product Owner is available.
Topic: Scrum Team and Accountabilities
Midway through a Sprint, several stakeholders ask the Developers to review a new idea and “just add it to this Sprint” so they can see it quickly. The Sprint Goal is still achievable, and the Product Owner is available.
What is the best Scrum-aligned way to involve the stakeholders so their feedback is useful without derailing the Sprint?
Best answer: C
What this tests: Scrum Team and Accountabilities
Explanation: Scrum uses the Sprint Review to inspect the Increment with stakeholders and adapt the Product Backlog based on feedback. Mid-Sprint, changes should be managed to protect focus on the Sprint Goal, with the Product Owner responsible for capturing and ordering new ideas. This keeps feedback timely and transparent without turning the Sprint into ad-hoc work.
To get useful stakeholder feedback without disrupting the Sprint, use the existing Scrum events and accountabilities. Stakeholders collaborate with the Scrum Team at the Sprint Review to inspect the current Increment and discuss what to do next. When a new idea appears mid-Sprint, the Product Owner should capture it in the Product Backlog and decide its ordering relative to other work. The Developers then continue to manage the Sprint Backlog toward the Sprint Goal, only renegotiating scope with the Product Owner if needed.
This approach preserves empiricism: transparency through the Product Backlog, inspection at Sprint Review, and adaptation by adjusting the Product Backlog rather than injecting unmanaged work into the Sprint.
Stakeholder feedback is primarily inspected at Sprint Review, while the Product Owner orders new ideas in the Product Backlog without disrupting the Sprint Goal.
Topic: Applying Scrum in Practice
It is Day 6 of a 10-day Sprint. The burndown chart shows the team is “behind,” but the Developers believe the most important slice of functionality is already integrated and the remaining work is mostly cleanup and tests. A stakeholder asks the Scrum Master for a status update.
What is the most Scrum-aligned way to describe and inspect progress in this situation?
Best answer: D
What this tests: Applying Scrum in Practice
Explanation: Within a Sprint, the Sprint Goal is the primary reference for progress and decision-making. Task completion trends and charts can support transparency, but they do not replace inspecting whether the Sprint Goal is still achievable. The appropriate response is to inspect progress toward the Sprint Goal and adapt the plan (Sprint Backlog) as needed.
The Sprint Goal is the single objective for the Sprint and the best primary evidence of progress during the Sprint is whether the Scrum Team is on track to achieve it. The Sprint Backlog (including tasks) is a plan by and for the Developers; it is expected to change as they learn.
In this situation, a “behind” burndown is only a signal to inspect. The Scrum-aligned approach is to:
Metrics can inform inspection, but the Sprint Goal is the primary progress reference.
In Scrum, progress within the Sprint is primarily inspected against the Sprint Goal, with the Sprint Backlog adapted as the plan to achieve it.
Topic: Artifacts, Commitments, and Done
During a Sprint Review, stakeholders are shown a new “Export to CSV” feature. The Developers had marked the Product Backlog item as Done because it met the acceptance criteria. After the Review, they realize the work did not pass the security scan that is explicitly required by the Scrum Team’s Definition of Done.
Which TWO actions are most appropriate to correct this “done but not done” situation?
Correct answers: E, F
What this tests: Artifacts, Commitments, and Done
Explanation: In Scrum, “Done” means the work meets the Definition of Done; otherwise it is not a usable Increment. The correction is to restore transparency by not presenting the work as part of the Increment and by making the remaining work visible on the Product Backlog so it can be completed properly.
“Done but not done” happens when work appears finished (e.g., acceptance criteria met) but does not meet the Definition of Done, so it is not a usable Increment. The appropriate response is to make the reality transparent and preserve the integrity of the Increment.
In this case:
Changing rules midstream or hiding incomplete work undermines transparency and weakens empiricism.
Work that does not meet the Definition of Done cannot be part of the Increment and must be made transparent.
The incomplete work should be captured and ordered so it can be completed to the Definition of Done in a future Sprint.
Topic: Artifacts, Commitments, and Done
A Scrum Team is in a 2-week Sprint with 7 days remaining. On their Sprint board they have written three separate “Sprint Goals”:
Daily Scrums keep shifting between these three outcomes, and stakeholders are asking what the Sprint will actually deliver. The Definition of Done requires each change to be integrated and tested in a shared staging environment.
What is the BEST next action?
Best answer: A
What this tests: Artifacts, Commitments, and Done
Explanation: A Sprint has a single Sprint Goal that provides focus and a shared objective for the Developers’ plan. Using multiple Sprint Goals fragments inspection and adaptation and reduces transparency about what the Sprint is trying to achieve. The Scrum-aligned correction is to collaborate to define one Sprint Goal and then adjust the Sprint Backlog to support it while maintaining the Definition of Done.
The Sprint Goal is the single objective for the Sprint and is the commitment for the Sprint Backlog. When a team uses multiple “Sprint Goals,” they lose the focus and coherence that the Sprint Goal is meant to create, and stakeholders cannot clearly inspect what value the Sprint is aiming to deliver.
Best next action is to quickly re-align (Product Owner with Developers) on one Sprint Goal that represents the most valuable outcome for this Sprint, then make the Sprint Backlog transparent as the plan to meet it:
This keeps empiricism intact: clear transparency, frequent inspection of progress toward one goal, and adaptation of the plan without lowering quality.
Scrum has one Sprint Goal that provides focus, so the team should re-align on a single objective and adjust the Sprint Backlog transparently.
Topic: Scrum Events and Timeboxes
A Scrum Team delivers a Done Increment each Sprint. However, the organization has introduced a rule: “Work from Sprint N cannot be continued in Sprint N+1 until stakeholders sign an approval document in the Sprint Review.” This often delays starting the next Sprint by several days.
What is the best Scrum-aligned correction?
Best answer: A
What this tests: Scrum Events and Timeboxes
Explanation: Using stakeholder sign-off to allow the next Sprint to begin turns the Sprint into a phase gate and breaks the fixed timebox. In Scrum, the Sprint Review is a collaborative inspection and adaptation event, not an approval checkpoint. The Scrum Master should help stakeholders and the organization understand how to use the Review and feedback without delaying the next Sprint.
A Sprint is a fixed-length event that provides cadence; it is not a stage-gate that must be “passed” to start the next Sprint. The Sprint Review’s purpose is to inspect the outcome of the Sprint and determine future adaptations, typically by adjusting the Product Backlog based on what was learned. If stakeholders want to provide feedback or express concerns, that input can be incorporated into Product Backlog ordering, acceptance criteria, or the Definition of Done as appropriate.
The Scrum-aligned correction is to remove the approval gating behavior and use the Sprint Review for transparency and adaptation, while the next Sprint starts on time with a Sprint Goal and updated plan.
The Sprint Review is for inspecting outcomes and adapting the Product Backlog, while the Sprint timebox continues and the Product Owner decides what to do next.
Topic: Scrum Theory, Values, and Empiricism
During the Sprint Review, the Developers demonstrate several Product Backlog Items they marked as “Done.” Some stakeholders say the work is not acceptable because performance and security expectations were never stated, and the Scrum Team cannot point to a shared Definition of Done or clear acceptance criteria. The team instead reports “progress” using hours spent and tasks closed.
Which observation is the best evidence that inspection is currently ineffective due to unclear goals or quality criteria?
Best answer: B
What this tests: Scrum Theory, Values, and Empiricism
Explanation: Inspection in Scrum depends on transparency of what is being inspected and the criteria used to judge it. When quality expectations, acceptance criteria, and the Definition of Done are unclear, people cannot reliably determine whether an Increment is usable or whether progress toward goals was made. Disagreement about what “Done” means is a strong indicator that inspection is ineffective.
Effective inspection requires transparent standards for “what good looks like” so the Scrum Team and stakeholders can compare the Increment to agreed expectations. In Scrum, this is primarily enabled by a clear Definition of Done (for releasability and quality) and clear Product Backlog Item acceptance criteria (for specific outcomes), along with a meaningful Sprint Goal/Product Goal (for progress). If those criteria are missing or vague, teams may still inspect activity measures (hours, tasks, velocity), but those do not validate usable progress or value. Persistent debate about whether work is truly “Done” indicates the criteria are not transparent, so inspection cannot produce dependable insights and adaptation becomes guesswork.
Key takeaway: disagreements about completeness/releasability point to unclear quality criteria, not a lack of effort.
Without clear, shared quality criteria, the Increment cannot be inspected meaningfully for progress or value.
Topic: Scrum Theory, Values, and Empiricism
Mid-Sprint, a new Scrum Master who used to be the team’s line manager starts assigning tasks to individual Developers and requires each Developer to give a daily status report to the Scrum Master, who then updates the Sprint Backlog alone.
What is the most likely near-term impact?
Best answer: D
What this tests: Scrum Theory, Values, and Empiricism
Explanation: This anti-pattern turns the Scrum Master into a task manager, which undermines the Developers’ self-management and shifts the Daily Scrum toward status reporting. The immediate result is reduced transparency about real progress and impediments, which delays inspection and adaptation needed to make progress toward the Sprint Goal.
In Scrum, the Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and serving the Scrum Team and organization—not managing individuals, assigning work, or acting as a reporting gate. When a Scrum Master assigns tasks and collects status, Developers are less likely to openly surface impediments and adjust their plan together.
Near-term, this most directly harms empiricism:
The key takeaway is that the Developers own the Sprint Backlog and the day-to-day plan to achieve the Sprint Goal; the Scrum Master enables this rather than directing it.
Treating the Scrum Master as a manager encourages reporting and hides real progress/impediments, weakening empiricism and immediate Sprint Goal focus.
Topic: Scrum Theory, Values, and Empiricism
During a Sprint, the Scrum Team’s Sprint Backlog shows most items as “Done.” A stakeholder asks whether the Increment is releasable today.
Exhibit (excerpt)
Definition of Done:
- Code merged to main branch
- Automated tests passing
- Integrated build is green
Sprint Backlog (today):
- PB-21 "Checkout validation" Status: Done CI: failing
- PB-24 "Receipt email" Status: Done CI: failing
What is the best next action to improve transparency of quality based on this exhibit?
Best answer: A
What this tests: Scrum Theory, Values, and Empiricism
Explanation: In Scrum, “Done” means the work meets the Definition of Done, which creates transparency about quality. The exhibit shows CI failing while items are marked “Done,” so quality is not transparent. The best action is to align the Sprint Backlog’s status with the Definition of Done and expose test/integration status so inspection and adaptation are based on reality.
Transparency of quality comes from a clear Definition of Done and truthful reporting of whether it is met. Here, the Definition of Done requires automated tests passing and an integrated green build, but the Sprint Backlog marks items as “Done” while CI is failing. That mismatch hides quality and undermines empiricism.
A better approach is to:
Changing labels, extending timeboxes, or bypassing the Definition of Done reduces transparency instead of improving it.
If tests and integration are failing, the work does not meet the Definition of Done and the Sprint Backlog should transparently reflect that.
Topic: Scrum Team and Accountabilities
Halfway through a 2-week Sprint, a stakeholder asks for a new reporting feature “as soon as possible.” The Scrum Team has a clear Sprint Goal and is on track to meet the Definition of Done.
The Product Goal is: “Enable customer self-service to reduce support tickets by 20%.”
As Product Owner, what is the BEST next action?
Best answer: A
What this tests: Scrum Team and Accountabilities
Explanation: The Product Goal describes the future state the Product Backlog should help achieve, so it should guide how the Product Owner orders Product Backlog items. New stakeholder requests are considered by their contribution to the Product Goal (or by updating the Product Goal when appropriate). The resulting ordering should be made transparent so the Scrum Team can make informed decisions in future Sprints.
The Product Goal is the long-term objective for the Scrum Team, and the Product Backlog is an ordered, emergent list of what is needed to improve the product. The Product Owner is accountable for ordering the Product Backlog to maximize value, and the Product Goal provides the key context for that ordering.
In this situation, the best next step is to assess the reporting request against the Product Goal and then reorder the Product Backlog accordingly, communicating the rationale so it is transparent. If the request reveals a change in desired outcomes, the Product Owner can collaborate with stakeholders to adapt the Product Goal, and then reorder the backlog to align with the new direction. The takeaway: ordering is not “first come, first served”; it is driven by the Product Goal and value.
The Product Goal provides direction for ordering the Product Backlog to maximize value, while keeping changes transparent without disrupting the current Sprint.
Topic: Scrum Team and Accountabilities
Midway through a Sprint, the Developers start adding new Product Backlog items from stakeholder emails and re-ordering the top of the Product Backlog themselves because the Product Owner is “too busy.” The Scrum Master says this is fine as long as the team keeps working toward the Sprint Goal.
What is the most likely near-term impact of this change?
Best answer: D
What this tests: Scrum Team and Accountabilities
Explanation: The Product Owner is accountable for managing the Product Backlog, including its ordering and making it transparent and understood. When others change and re-order items without the Product Owner, the near-term consequence is confusion and reduced transparency about upcoming work. That weakens inspection and adaptation around what delivers the most value next.
In Scrum, the Product Owner is accountable for maximizing value and for managing the Product Backlog. Managing the Product Backlog includes ensuring it is transparent, visible, and understood, and ordering it to best achieve the Product Goal. Others may help with refinement, but when Developers and the Scrum Master unilaterally add and re-order items, there is no clear accountability for Product Backlog content and ordering.
Near-term, this reduces transparency for the Scrum Team and stakeholders about what work is actually prioritized next, making inspection and adaptation harder and increasing the risk of misalignment with value. This is different from issues like canceling a Sprint or changing quality rules, which are not automatic consequences of who manages the backlog.
The Product Owner is accountable for managing the Product Backlog, so bypassing them quickly makes ordering/content less transparent and harder to inspect.
Topic: Artifacts, Commitments, and Done
At the end of a Sprint, the Scrum Team has integrated the new work with all previous work, and the result is usable and provides value. It meets the team’s Definition of Done and could be released immediately if the Product Owner chooses.
Which Scrum concept is being described?
Best answer: D
What this tests: Artifacts, Commitments, and Done
Explanation: This describes an Increment: a coherent, integrated step toward the Product Goal that is usable and valuable. To qualify as an Increment, it must meet the Definition of Done so its state is transparent and it can be released if desired.
An Increment is the integrated result of completed work that provides value and moves the product toward the Product Goal. It is not just “work done by individuals” or “items finished in development”; it is the sum of all completed Product Backlog items for the Sprint plus the value of prior Increments, combined into a usable whole. A key requirement is that the Increment meets the Definition of Done, which makes the Increment’s quality and completeness transparent and ensures it is in a usable state. Because it is usable and meets the Definition of Done, an Increment is potentially releasable at any time—release is a business decision, but the Increment must be ready.
Key takeaway: “Potentially releasable and meeting the Definition of Done” points to the Increment, not the plans or rules around the work.
An Increment is the sum of all Product Backlog items completed during a Sprint and previous Sprints that is usable, valuable, and meets the Definition of Done.
Topic: Scrum Events and Timeboxes
During Sprint Planning, a Scrum Team discusses the Product Goal and forecasts work for the upcoming Sprint. Afterward, the Scrum Master wants evidence that the team covered the three Sprint Planning topics (why, what, how) in a way that supports empiricism.
Which indicator best validates that Sprint Planning achieved its intent?
Best answer: C
What this tests: Scrum Events and Timeboxes
Explanation: Sprint Planning is successful when it produces a clear Sprint Goal, a forecast of Product Backlog Items to meet it, and an initial plan for delivering them. The most direct evidence is the Sprint Backlog, because it captures the why, what, and how in a transparent artifact the Scrum Team can inspect and adapt during the Sprint.
The three Sprint Planning topics are why, what, and how. “Why” is expressed as a Sprint Goal that explains the value the Sprint intends to deliver. “What” is the Developers’ selection of Product Backlog Items they forecast can be completed to support that Sprint Goal. “How” is the plan for turning those selected items into a Done Increment, evolving the Sprint Backlog as more is learned.
The best validation that these topics were addressed is a Sprint Backlog that includes:
Meeting artifacts, attendance, or point commitments do not validate value or a coherent plan to achieve the Sprint Goal.
This reflects the why (Sprint Goal), what (PBIs), and how (plan) outcomes of Sprint Planning.
Topic: Scrum Theory, Values, and Empiricism
Which statement best describes a Sprint in Scrum?
Best answer: D
What this tests: Scrum Theory, Values, and Empiricism
Explanation: In Scrum, a Sprint is a fixed-length timebox of one month or less in which the Scrum Team works toward a Sprint Goal and creates at least one Done, usable Increment. Treating timeboxes as sequential phases or gates is characteristic of phase-gate management, not Scrum’s iterative and incremental approach.
A Sprint is the container event for all other Scrum events and the cadence for empiricism. Each Sprint has a consistent duration (one month or less) and is used to create a valuable, usable Increment that meets the Definition of Done, supporting progress toward the Product Goal. Work is not managed as separate sequential phases (e.g., “analysis Sprint” then “build Sprint” then “test Sprint”) or as stage gates requiring approval to move forward. Using Scrum terms while still organizing delivery around phase gates reduces transparency and delays inspection and adaptation because value is not integrated and assessed frequently as a Done Increment.
Key takeaway: a Sprint is an iterative timebox producing Done value, not a phase or gate.
A Sprint is a timebox in which Scrum Team members work toward a Sprint Goal and create at least one Done, usable Increment.
Topic: Artifacts, Commitments, and Done
Midway through a Sprint, a stakeholder asks, “What are you working on next, and do you still believe you can meet the Sprint Goal?” The Developers realize their task breakdown and remaining work have not been updated since Sprint Planning.
Which response best aligns with Scrum and addresses the stakeholder’s need for transparency?
Best answer: A
What this tests: Artifacts, Commitments, and Done
Explanation: The Sprint Backlog is owned by the Developers and is a living plan for how they will achieve the Sprint Goal. Keeping it up to date makes transparent the work the Developers plan to accomplish in the Sprint and their current plan (including remaining work) to deliver it. Updating it directly addresses the stakeholder’s question without adding extra artifacts or shifting accountability.
In Scrum, the Sprint Backlog is the plan by and for the Developers. It includes the Sprint Goal, the Product Backlog items selected for the Sprint, and an actionable plan for delivering the Increment. Because the Sprint Backlog is updated throughout the Sprint as more is learned, it makes transparent what the Developers intend to do and how they currently plan to achieve the Sprint Goal (including what work remains).
When stakeholders ask about “what’s next” and likelihood of meeting the Sprint Goal, the most Scrum-aligned response is to ensure the Sprint Backlog reflects the Developers’ current understanding and plan. This preserves empiricism by improving transparency and enabling better inspection and adaptation.
The Sprint Backlog is the Developers’ transparent, updated plan for achieving the Sprint Goal, including the work selected and the work remaining.
Topic: Scrum Team and Accountabilities
A Scrum Team frequently plans a Sprint by pulling enough Product Backlog Items to keep every Developer “100% utilized.” When someone finishes early, they start another item so no one is idle. The Sprint Backlog is visible and updated daily, and the Definition of Done is clear and met.
Despite lots of activity, the team often reaches the Sprint Review with only a couple of Done items and many items partially started.
What is the most likely underlying cause in Scrum terms?
Best answer: A
What this tests: Scrum Team and Accountabilities
Explanation: Maximizing individual utilization is a common local optimization when the Sprint is treated as a capacity-filling exercise. A clear Sprint Goal provides focus and a decision filter for whether to start new work or swarm to finish the most valuable items. Without that shared objective, work tends to fragment, WIP grows, and fewer items reach Done.
In Scrum, Developers self-manage to achieve the Sprint Goal, not to keep everyone continuously busy. When the Sprint Goal is unclear or absent, the Sprint can devolve into “fill the timebox” planning and individual task utilization. That encourages starting additional work whenever someone is free, which increases work in progress and reduces the team’s ability to finish a Done Increment.
A healthier approach is to use a clear Sprint Goal to focus choices during the Sprint (for example, swarming to complete the most important work and avoiding starting new items that don’t help meet the goal). The key takeaway is that focus on a cohesive Sprint Goal beats maximizing utilization.
Without a clear Sprint Goal to guide decisions, the Developers optimize for being busy and start more work, increasing WIP and reducing completed value.
Topic: Scrum Events and Timeboxes
Halfway through a Sprint, the Developers discover that a key Product Backlog Item needed to meet the Sprint Goal is blocked by an external dependency. During the Daily Scrum they agree to stop mentioning the blockage, do not update the Sprint Backlog, and start pulling in other work that is not related to the Sprint Goal so they “stay productive.”
What is the most likely near-term impact of this decision?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: The Daily Scrum exists to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. Hiding a blockage and continuing with unrelated work removes transparency about actual progress, preventing timely adaptation. The near-term consequence is increased risk of not meeting the Sprint Goal because decisions are being made with incomplete information.
When work is blocked during the Sprint, the key need is to maintain transparency so the Developers can inspect progress toward the Sprint Goal and adapt their plan (the Sprint Backlog) accordingly. The Daily Scrum is the primary moment for the Developers to surface impediments, re-plan, and coordinate next steps for the next 24 hours.
If the Developers stop mentioning the blockage and do not update the Sprint Backlog, they create a false picture of progress. Pulling in unrelated work further obscures whether the Sprint Goal is still achievable and delays decisions such as seeking help, negotiating scope, or collaborating with the Product Owner on options. The immediate effect is reduced transparency and poorer ability to inspect and adapt toward the Sprint Goal.
Not surfacing the blockage and not updating the Sprint Backlog hides reality, so the Scrum Team cannot reliably inspect progress toward the Sprint Goal and adapt.
Topic: Artifacts, Commitments, and Done
A stakeholder asks the Scrum Master, “What are we building next, and why is that the priority?” The Product Owner is not available, and the stakeholder expects a quick, confident answer.
What should the Scrum Master verify or observe first before responding?
Best answer: B
What this tests: Artifacts, Commitments, and Done
Explanation: The Product Backlog is the single, transparent source of work needed to improve the product. To answer what is likely next and why, the first thing to check is the Product Backlog content and its ordering. That provides the best available transparency when the Product Owner is not immediately present.
In Scrum, the Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the primary artifact to inspect when someone asks what the team is likely to do next because it makes transparent the currently known work and its relative priority.
Looking at the Product Backlog items and their ordering allows a response grounded in transparency (what is known and ordered today), while also making it clear that the Product Owner remains accountable for Product Backlog ordering and communicating value. Other information (like capacity, Definition of Done, or additional stakeholder requests) can matter, but it does not replace the Product Backlog as the first place to verify what is currently expected next.
The Product Backlog makes transparent what is needed to improve the product and, through ordering, what is most important next.
Topic: Scrum Events and Timeboxes
Mid-Sprint, the Scrum Master notices the Developers’ Daily Scrum has turned into a 30-minute status meeting where each person reports what they did yesterday and waits for direction. The team says, “We’re doing the Daily Scrum like management expects.”
Before suggesting changes to how they use the Daily Scrum, what should the Scrum Master ask or verify first?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: The Daily Scrum exists for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog plan for the next day of work. Verifying the Sprint Goal and the team’s next-24-hours plan directly checks whether the event is being used for its intended purpose. Once that is clear, the Scrum Master can help the team refocus the Daily Scrum away from status reporting and toward planning work that advances the Sprint Goal.
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. If the team is treating it as a status meeting, the first thing to clarify is whether the conversation is anchored on the Sprint Goal and producing a usable plan for the next day.
A helpful first check is:
If the Daily Scrum results in a clear, developer-owned plan that advances the Sprint Goal, it is serving its purpose; who “expects” status updates is a separate concern.
The Daily Scrum’s purpose is to inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours.
Topic: Scrum Team and Accountabilities
Mid-Sprint, the Developers update the Sprint Backlog after learning that integrating the email service is more complex than expected.
Sprint Goal: Users can reset password via email
Sprint Backlog (excerpt)
- PBI-21 Password reset email (In Progress)
Remaining work: was 12h, now 28h
- PBI-19 Reset UI copy (To Do) Remaining: 6h
- PBI-22 Audit log entry (To Do) Remaining: 8h
What is the best next action for the Developers?
Best answer: A
What this tests: Scrum Team and Accountabilities
Explanation: When work turns out larger than expected, Developers update the Sprint Backlog and adjust their plan for the Sprint. Because the change threatens achieving the Sprint Goal, they should also make the impact transparent and collaborate with the Product Owner on scope and ordering trade-offs within the Sprint. This supports inspection and adaptation while keeping focus on the Sprint Goal.
The Developers own the Sprint Backlog and are accountable for creating a plan for the Sprint that can be adapted as more is learned. An increase in remaining work is a signal to inspect progress and adapt immediately, not to hide the issue or change quality. Practical Developer actions include:
Timeboxes are fixed, and “Done” quality is not negotiable; adaptation happens through re-planning and transparent collaboration.
Developers can adapt their plan at any time and should make scope/plan trade-offs transparent with the Product Owner when the Sprint Goal is at risk.
Topic: Applying Scrum in Practice
Several Scrum Teams in your organization build one product. An organizational policy says stakeholders may not see working software until a quarterly “Release Readiness” meeting, so Sprint Reviews are replaced by written status reports.
Teams report increasing rework because feedback arrives months late. As Scrum Master for one of the teams, what is the best next step?
Best answer: A
What this tests: Applying Scrum in Practice
Explanation: The policy blocks transparency and inspection by preventing stakeholders from seeing the Increment each Sprint. The Scrum-aligned response is to address the organizational constraint, not work around it with reports or extra gates. Changing the policy to allow stakeholders to inspect a Done Increment at Sprint Review restores timely feedback and adaptation.
When an organizational policy prevents stakeholders from inspecting the Increment frequently, it conflicts with empiricism by reducing transparency and delaying inspection and adaptation. In Scrum, the Sprint Review exists to inspect the outcome of the Sprint and adapt the Product Backlog based on stakeholder feedback.
A Scrum-aligned next step is for the Scrum Master to help the organization change the policy and create conditions for effective Sprint Reviews, for example by:
Workarounds that keep stakeholders from seeing the Increment (or add extra approval steps) preserve the root problem and continue delaying feedback.
Empiricism requires transparency and frequent inspection of the Increment, so enabling real stakeholder inspection each Sprint is the Scrum-aligned change.
Topic: Scrum Events and Timeboxes
During Sprint Planning, the Developers select 10 Product Backlog Items and draft a Sprint Goal. Partway through planning, a Developer says, “This Sprint Backlog feels unrealistic,” but no one has discussed expected capacity changes or how the work will meet the Definition of Done.
What should the Scrum Master encourage the Scrum Team to verify or ask FIRST before deciding how to adjust the Sprint Backlog?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: An unrealistic Sprint Backlog is primarily a mismatch between what the Developers forecast and what they can actually deliver as a Done Increment within the Sprint. Before changing scope or commitments, the team needs transparency about capacity and the ability to meet the Definition of Done for the selected work.
In Sprint Planning, the Developers forecast the work they believe they can accomplish to meet the Sprint Goal, and the Sprint Backlog is a plan by and for the Developers. If someone suspects the Sprint Backlog is unrealistic, the first step is to make the situation transparent by checking the Developers’ expected capacity (e.g., availability, other obligations) and whether the selected Product Backlog Items can be completed to the Definition of Done within the Sprint.
Once that information is clear, the Scrum Team can adapt by adjusting the Sprint Backlog (e.g., removing or splitting items, renegotiating scope with the Product Owner) while keeping the Sprint Goal as the guiding constraint. Seeking more stakeholder wishes or demanding overly detailed plans does not address the core question of feasibility to Done.
Realism depends first on what the Developers can accomplish to Done given their capacity and quality constraints.
Topic: Scrum Theory, Values, and Empiricism
During Sprint Planning for a product in a volatile market, a manager asks the Scrum Team to create a detailed plan for the next three Sprints (task-level breakdowns and fixed scope) so progress can be “predicted and controlled.” The Product Owner agrees and tells Developers that changes to the plan will require approval outside the Scrum Team.
What is the most likely near-term impact?
Best answer: C
What this tests: Scrum Theory, Values, and Empiricism
Explanation: Scrum is designed for complex problems where outcomes and paths to them cannot be reliably predicted upfront. Forcing a fixed, detailed multi-Sprint plan shifts focus from empiricism to controlling a forecast, which reduces transparency about what is really known and makes it harder to adapt when new information appears. The near-term effect is typically poorer inspection and adaptation, not better predictability.
Scrum assumes complex work: what to build and how to build it will be discovered through frequent delivery and feedback. In complex domains, detailed forecasts across multiple Sprints rapidly become wrong because learning, technology, and stakeholder needs change.
When the Scrum Team is pressured to “lock” scope and task plans for several Sprints and require external approval for changes, it weakens empiricism:
Scrum manages complexity by short feedback loops and adaptation around a Sprint Goal, not by multi-Sprint control plans.
In complex work, detailed multi-Sprint predictions quickly become unreliable and discourage inspection and adaptation to new learning.
Topic: Artifacts, Commitments, and Done
A Scrum Team has a 2-week Sprint and a clear Definition of Done. Near the end of the Sprint, the Developers say most Product Backlog Items are “code complete” but still need integration testing and documentation, so they plan to demonstrate them at the Sprint Review anyway and “finish them next Sprint.”
What is the most likely near-term impact at the Sprint Review?
Best answer: D
What this tests: Artifacts, Commitments, and Done
Explanation: The Sprint Review is for inspecting the outcome of the Sprint and adapting based on what was actually accomplished. If the work does not meet the Definition of Done, it is not part of the Increment and cannot provide the transparency needed for reliable inspection. Showing incomplete work risks decisions being made on assumptions rather than a usable Increment.
A Done Increment each Sprint is essential because it is the concrete, usable outcome that stakeholders can inspect at the Sprint Review. “Code complete” work that still lacks required testing/documentation does not meet the Definition of Done, so it is not transparent as an Increment and should not be treated as completed progress. When a Scrum Team presents unfinished work, the Sprint Review conversation can drift into speculation (what will work, what will be ready, what quality risks remain) instead of inspection of a real Increment and adaptation of the Product Backlog based on current reality. The key takeaway is that the Definition of Done creates a shared quality bar so inspection at the Sprint Review is based on what is actually usable, not what is hoped to be finished soon.
Without a Done Increment, transparency is reduced and stakeholders cannot reliably inspect what is truly usable to adapt the Product Backlog.
Topic: Scrum Events and Timeboxes
At the end of a Sprint, the Scrum Team has completed three Product Backlog Items that meet the Definition of Done. A fourth item is “almost finished” but still lacks required tests, so it does not meet the Definition of Done.
Stakeholders attending the Sprint Review ask to see everything the team worked on, including the “almost finished” item. What is the best Scrum-aligned approach?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Review inspects the Increment, which is the sum of all Product Backlog Items completed during the Sprint that meet the Definition of Done. Work that is not Done is not part of the Increment and should not be presented as such. The team can still be transparent by discussing what remains and adapting the Product Backlog based on what they learned.
In Scrum, the Sprint Review’s purpose is to inspect the outcome of the Sprint and determine future adaptations. The “outcome” being inspected is the Increment, and the Increment contains only work that meets the Definition of Done.
So the Scrum Team should:
Transparency is achieved by discussing unfinished work, but presenting it as part of the Increment undermines the Definition of Done and reduces the quality of inspection.
At the Sprint Review, only work that meets the Definition of Done is part of the Increment to be inspected, while unfinished work can be discussed to adapt the Product Backlog.
Topic: Scrum Theory, Values, and Empiricism
A Scrum Team frequently meets its “component output” targets: the database specialist completes many database tasks and the UI specialist completes many UI tasks each Sprint. However, most Product Backlog Items are only “almost done” because integration and end-to-end testing happen late, so little is usable at the Sprint Review.
What is the best Scrum-aligned adjustment to improve overall value delivery?
Best answer: B
What this tests: Scrum Theory, Values, and Empiricism
Explanation: The team is optimizing local activity (component output) at the expense of the system outcome: a usable Increment. A systems-oriented adjustment is to limit work in progress and swarm to complete end-to-end slices that meet the Definition of Done, enabling real inspection and adaptation at the Sprint Review.
Lean thinking emphasizes optimizing the whole system for value delivery, not maximizing local efficiency. In this scenario, specialists are “busy” and local output looks good, but the system produces little usable value because integration and testing are deferred, creating queues and rework.
A Scrum-aligned adjustment is to change how the Developers manage their work so they can finish PBIs to the Definition of Done throughout the Sprint, for example:
The key takeaway is to optimize for a Done Increment that meets the Sprint Goal, not for specialist throughput.
It shifts focus from optimizing component throughput to optimizing flow to a Done Increment that can be inspected for value.
Topic: Artifacts, Commitments, and Done
Midway through a Sprint, a stakeholder asks the Scrum Team, “How do we know we are on track to meet the Sprint Goal?” The Developers want to point to a single piece of evidence that best aligns with Scrum and explains what the Sprint Backlog makes transparent.
Which is the best evidence/indicator?
Best answer: B
What this tests: Artifacts, Commitments, and Done
Explanation: The Sprint Backlog is a plan by and for the Developers and is updated throughout the Sprint. Keeping it current makes transparent what work remains and how the Developers intend to achieve the Sprint Goal. This provides the most Scrum-aligned evidence of whether they believe they are on track.
In Scrum, the Sprint Backlog consists of the Sprint Goal, the Product Backlog items selected for the Sprint, and an actionable plan for delivering the Increment. It is owned and continuously updated by the Developers as they learn more during the Sprint.
Because it is updated, the Sprint Backlog makes transparent:
Measures like time spent or percent-complete can be misleading because they do not directly show the Developers’ current plan to achieve the Sprint Goal; the Sprint Backlog exists to provide that transparency.
The Sprint Backlog is the Developers’ plan for the Sprint and makes transparent the work they believe is needed to achieve the Sprint Goal, including progress as it is updated.
Topic: Applying Scrum in Practice
Mid-Sprint, the Developers report they spent two days fixing urgent production incidents. Stakeholders are asking why “progress” looks slow.
Exhibit: Sprint Backlog excerpt
Sprint Goal: Enable customers to reset passwords
Planned PBIs: PBI-21 Reset flow (8), PBI-34 Email template (5), PBI-35 Audit log (3)
In progress: PBI-21 (3/8), PBI-34 (2/5)
Done: none
Note from Developers: “2 days on INC-17/INC-18 (not on board)”
What is the best next action?
Best answer: B
What this tests: Applying Scrum in Practice
Explanation: The exhibit shows unplanned operational work consuming significant time but not being represented in the Sprint Backlog, reducing transparency. In Scrum, Developers update the Sprint Backlog to reflect all work needed to meet the Sprint Goal and collaborate with the Product Owner to adapt scope when emergent work occurs. Making the work visible enables realistic inspection and adaptation during the Sprint.
Unplanned operational work (like production incidents) is legitimate work, but it must not be hidden. The Sprint Backlog is a plan by and for the Developers and should be updated as work emerges, including urgent incidents that consume capacity. Once the work is transparent, the Scrum Team can inspect progress toward the Sprint Goal and adapt by renegotiating the Sprint Backlog with the Product Owner (for example, removing or slicing PBIs, or rethinking the plan) while keeping the Sprint Goal in focus. Hiding work to “protect velocity” undermines empiricism and prevents stakeholders from understanding current reality. The key is transparency first, then inspection and adaptation of the plan.
Unplanned operational work should be made transparent in the Sprint Backlog and used to adapt the Sprint plan with the Product Owner.
Topic: Scrum Theory, Values, and Empiricism
During a Sprint, the Developers hold a 15-minute Daily Scrum where each person reports progress to the Product Owner, who then asks for updated dates. The Developers rarely adjust their plan during the meeting.
As Scrum Master, what should you verify or ask FIRST before deciding how to improve this?
Best answer: C
What this tests: Scrum Theory, Values, and Empiricism
Explanation: A Daily Scrum should be used by the Developers to inspect progress toward the Sprint Goal and adapt the plan in the Sprint Backlog. Before proposing changes, confirm whether there is a clear, shared Sprint Goal and whether the Developers view the Daily Scrum as a planning event for the next day. That information directly explains why the meeting is becoming a status report and what to change.
Using the Daily Scrum as a status meeting is an anti-pattern because it shifts the event from Developers’ planning and adaptation to reporting for someone else. The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.
The most useful first check is whether the Developers have a clear Sprint Goal and whether they can describe how the Daily Scrum helps them update their plan for the next 24 hours. If the goal is unclear or the event doesn’t produce an adjusted plan, improvements should focus on restoring the Developers’ ownership of the event and re-centering it on the Sprint Goal and Sprint Backlog, rather than on reporting to the Product Owner.
The Daily Scrum is for Developers to plan work toward the Sprint Goal, so first verify goal clarity and whether the event results in an updated plan.
Topic: Scrum Events and Timeboxes
It is Day 6 of a 2-week Sprint. The Sprint Goal is: “Customers can reset their own password without support.”
A stakeholder asks the Developers to add an “admin reset password” button by Friday because support is overloaded. The team’s Definition of Done requires a security review for any authentication change, and the Developers are already busy finishing the self-service flow.
What is the BEST next action?
Best answer: A
What this tests: Scrum Events and Timeboxes
Explanation: The Sprint Goal provides cohesion and focus by giving the Scrum Team a shared objective to steer day-to-day decisions. When a new request arrives mid-Sprint, the Developers and Product Owner use the Sprint Goal to inspect whether the work supports it and adapt the Sprint Backlog accordingly. This keeps progress transparent and preserves quality by continuing to meet the Definition of Done.
The Sprint Goal is the single objective for the Sprint and is what creates focus and cohesion for the Scrum Team. During the Sprint, new information or requests can emerge, but changes to planned work are handled by inspecting them against the Sprint Goal and adapting the Sprint Backlog without undermining the Definition of Done.
A practical next step is:
The key is that the Sprint Goal guides what to keep, change, or defer so the team doesn’t lose coherence.
The Sprint Goal should guide whether and how to adapt the Sprint Backlog, and any change in direction is negotiated with the Product Owner while keeping work transparent and Done.
Topic: Artifacts, Commitments, and Done
A Scrum Team is finishing a Product Backlog Item (PBI). The Developers say it is “done” because it meets its acceptance criteria. However, the team’s Definition of Done requires integration testing and documentation updates, which are not completed.
Which TWO statements correctly distinguish the Definition of Done from acceptance criteria in this situation? (Select TWO)
Correct answers: B, C
What this tests: Artifacts, Commitments, and Done
Explanation: The Definition of Done is the Scrum Team’s transparent, shared standard that determines whether work is “Done” and contributes to a usable Increment. Acceptance criteria are specific to an individual Product Backlog Item and help the team and Product Owner align on what is needed for that item. Meeting acceptance criteria alone does not override failing the Definition of Done.
Definition of Done and acceptance criteria serve different purposes. The Definition of Done is a single, shared quality standard that must be met for work to be considered “Done” and for an Increment to be usable; it creates transparency about what it takes to produce a releasable Increment. Acceptance criteria are specific conditions for a particular Product Backlog Item, used to clarify understanding and validate whether that item delivers what was intended.
In this scenario, the PBI is not “Done” yet because it does not meet the team’s Definition of Done (integration testing and documentation). Acceptance criteria can help confirm the item’s functional intent, but they do not reduce the Definition of Done quality requirements.
The Definition of Done is a shared, consistent quality bar for any Increment created.
Acceptance criteria are item-specific checks used to understand and validate that PBI.
Topic: Scrum Theory, Values, and Empiricism
A Scrum Team delivers a payment feature over 2-week Sprints. Each Sprint they mark most Product Backlog items as “Dev complete” and plan a separate “hardening Sprint” every fourth Sprint for integration, security testing, and bug fixing. In Sprint Reviews they show partial demos and say “it will be fully tested later.” The Sprint Goal is clear and consistently focused on the payment outcome.
What is the most likely underlying Scrum cause of this waterfall-in-sprints behavior that should be corrected first?
Best answer: D
What this tests: Scrum Theory, Values, and Empiricism
Explanation: Creating “hardening Sprints” and calling items “Dev complete” are strong signals that the team is not aiming for a releasable Increment every Sprint. In Scrum, that typically happens when the Definition of Done is weak or not shared, so integration, security testing, and defect fixing are treated as a later phase rather than part of Done.
This scenario shows a classic “waterfall inside a Sprint”: build now, integrate/test later, and periodically run a hardening phase. In Scrum, the primary control that prevents this is a strong, shared Definition of Done that makes quality and completeness transparent and required for every Product Backlog item selected for the Sprint.
Correcting it means making “Done” include the necessary work to produce a usable Increment each Sprint (e.g., integration, testing, and any required security checks), and then planning and collaborating to meet that DoD within the Sprint. A clear Sprint Goal helps focus, but it cannot compensate for a DoD that allows incomplete, non-releasable work to accumulate.
If “Done” does not include integration and testing, teams create mini-phases and hardening Sprints instead of a usable Increment each Sprint.
Topic: Scrum Team and Accountabilities
A Scrum Team is in the last week of a Sprint. Next Sprint Planning is tomorrow (timeboxed to 2 hours). The Product Backlog is transparent to stakeholders.
A stakeholder says a payment-security issue must be addressed before the next release in two weeks. Developers explain that fixing it depends on first upgrading a payment SDK, which is risky but reduces the chance of outages. The top of the Product Backlog currently focuses on features expected to increase checkout conversion.
What is the Product Owner’s BEST next action?
Best answer: A
What this tests: Scrum Team and Accountabilities
Explanation: The Product Owner is accountable for ordering the Product Backlog and should use inputs like value, risk, and dependencies to maximize value. Here, the dependency (SDK upgrade) and the risk of outages are critical ordering inputs alongside stakeholder value and release urgency. Making the ordering rationale transparent supports empiricism and better decisions in Sprint Planning.
Product Backlog ordering is the Product Owner’s accountability, and it should be informed by the best available inputs to maximize value. In this scenario, the stakeholder’s need creates high value/urgency, Developers have identified a clear dependency (upgrade before fix), and the security/outage exposure represents significant risk. The Product Owner should collaborate with Developers to understand these factors, then re-order the Product Backlog so the dependency and the risk-reducing work are appropriately placed relative to conversion features, and ensure the reasoning is visible to stakeholders.
Key takeaway: ordering is not delegated to Developers or driven by a single factor like effort; it is a value optimization decision that also considers risk and dependencies.
The Product Owner orders the Product Backlog and should consider value, risk, and dependencies (with Developers’ input) to maximize value and reduce risk.
Topic: Scrum Team and Accountabilities
A Scrum Team has delivered a Done Increment every Sprint and the Developers confirm the Definition of Done is clear and consistently met. The Sprint Goal for the last Sprint (“Enable self-service refunds”) was achieved.
At the Sprint Review, several key stakeholders are surprised and frustrated, saying they expected “bulk refunds” to be delivered first. They say they rarely see the Product Backlog, and the Product Owner typically shares only a quarterly roadmap slide deck and asks stakeholders to “wait until release.”
Which is the most likely underlying cause in Scrum terms?
Best answer: B
What this tests: Scrum Team and Accountabilities
Explanation: The symptoms show stakeholders are not regularly able to inspect current priorities and outcomes, so their expectations drift. In Scrum, ensuring transparency of the Product Backlog and actively engaging stakeholders to inspect progress and adapt direction is primarily the Product Owner’s accountability. Fixing that alignment mechanism addresses the root cause, not the team’s delivery quality.
When stakeholder expectations are unmanaged, look for missing transparency and weak stakeholder collaboration around what is being pursued next and why. Here, the Increment is Done and the Sprint Goal was achieved, which reduces the likelihood that delivery quality or Sprint execution is the issue.
The stronger clues are that stakeholders rarely see the Product Backlog and only get a high-level roadmap, and the Product Owner is deferring feedback until “release.” In Scrum, the Product Owner is accountable for making the Product Backlog transparent and for engaging stakeholders so they can inspect what was achieved and adapt future direction (often via the Sprint Review). The alignment action is to increase transparency and actively collaborate with stakeholders on ordering and upcoming outcomes, rather than relying on periodic roadmap broadcasts.
Clear delivery signals do not compensate for a lack of transparency about product direction.
Unmanaged expectations point to weak transparency and insufficient Product Owner collaboration with stakeholders to inspect and adapt direction.
Topic: Artifacts, Commitments, and Done
Midway through a Sprint, the Product Owner asks to directly add new work items to the Sprint Backlog in the team’s tool because a stakeholder request is urgent. Which Scrum concept best matches who owns the Sprint Backlog and who can change it?
Best answer: C
What this tests: Artifacts, Commitments, and Done
Explanation: In Scrum, the Sprint Backlog is an actionable plan for the Developers and is owned by them. As new information emerges during the Sprint, the Developers adapt the Sprint Backlog to meet the Sprint Goal. Others may propose changes, but they do not own or directly control the Sprint Backlog.
The Sprint Backlog is made up of the Sprint Goal, the Product Backlog items selected for the Sprint, and a plan for delivering them. It is owned by the Developers because it is their real-time picture of the work they believe is necessary to achieve the Sprint Goal.
During the Sprint, the Developers update the Sprint Backlog as they learn more (for example, by adding, splitting, or removing work and adjusting the plan). The Product Owner can clarify needs and negotiate scope, but does not “own” or directly change the Developers’ plan; the focus remains on enabling the Developers to manage their work to meet the Sprint Goal.
The Sprint Backlog is owned by the Developers and is updated by them throughout the Sprint.
Topic: Scrum Team and Accountabilities
A Scrum Team has been delivering a Done Increment every Sprint, but meaningful stakeholder feedback consistently arrives 6–8 weeks later, after a larger release. Stakeholders rarely attend the Sprint Review, and the Product Owner says the team is “building the wrong things” by the time feedback comes in.
Which TWO actions best improve the timing of stakeholder feedback within Scrum? (Select TWO)
Correct answers: A, B
What this tests: Scrum Team and Accountabilities
Explanation: The main problem is a delayed feedback loop, so the best actions are to create earlier, direct inspection of the Increment and enable faster validation. In Scrum, this is achieved by engaging stakeholders in the Sprint Review and by releasing Done Increments sooner so feedback is based on real product behavior, not assumptions.
When stakeholder feedback arrives weeks after development, inspection and adaptation are happening too late to avoid waste. Scrum’s primary mechanism for timely stakeholder feedback is the Sprint Review, where stakeholders and the Scrum Team inspect the Increment and collaborate on what to do next by adapting the Product Backlog.
Another way to improve timing is to reduce the delay between “Done” and actual use. Scrum allows releasing a Done Increment at any time, so releasing more frequently can shorten the learning cycle and make feedback concrete.
Options that add extra ceremonies, shift feedback into the Retrospective, or change accountabilities do not improve timely product inspection and adaptation.
The Sprint Review is the Scrum event designed for stakeholders and the Scrum Team to inspect the Increment and adapt the Product Backlog early.
A Done Increment can be released anytime, and more frequent releases shorten the feedback loop to support faster adaptation.
Topic: Scrum Theory, Values, and Empiricism
Midway through a Sprint, the Developers move several Product Backlog Items to “Done” on their board when coding is complete. However, integration happens near the end of the Sprint, the latest build is failing, and no test results are visible to the Scrum Team or stakeholders. The Product Owner expects to demonstrate these items at the Sprint Review.
What is the best next step to improve transparency of quality?
Best answer: C
What this tests: Scrum Theory, Values, and Empiricism
Explanation: Transparency of quality in Scrum comes from a clear Definition of Done and making the current state of testing and integration visible. If items are marked “Done” without meeting the Definition of Done, inspection at events is based on misleading information. The best next step is to align on and apply a Definition of Done that includes integration/testing and reflect that status transparently in the team’s work.
In Scrum, the primary mechanism for transparency of quality is the Definition of Done, which creates a shared understanding of what it means for work to be complete and usable. When the board shows “Done” but integration is failing and test results are not visible, the Sprint Backlog is not transparent and inspection at the Daily Scrum and Sprint Review will be based on inaccurate signals.
A good next step is:
This keeps progress and quality evidence transparent without adding non-Scrum gates or separate phases.
This makes quality transparent by using the Definition of Done and visible evidence (integration and test status) to represent real progress toward a Done Increment.
Topic: Artifacts, Commitments, and Done
During Product Backlog refinement, the Scrum Team discusses customer value, risk, and dependencies between items. After considering these inputs and the Product Goal, one person makes the final decision about the sequence of Product Backlog items.
Which Scrum concept best matches this situation?
Best answer: D
What this tests: Artifacts, Commitments, and Done
Explanation: In Scrum, the Product Owner is accountable for maximizing value and for ordering the Product Backlog. Ordering decisions can use any relevant information—commonly the Product Goal, expected value, risk, dependencies, and learning from previous Increments. The Scrum Team may collaborate in refinement, but accountability for ordering remains with the Product Owner.
The situation describes ordering work in the Product Backlog: many people can provide inputs, but one person is accountable for the final order. The Scrum Guide states that the Product Owner is accountable for the Product Backlog, including developing and explicitly communicating items and ordering them.
Ordering is not based on a single mandated technique; it can consider any information that helps optimize value and move toward the Product Goal, such as expected customer value, risk, dependencies, cost, and feedback from Sprint Reviews. Collaboration during refinement improves shared understanding, but it does not transfer accountability for ordering away from the Product Owner.
The Product Owner is accountable for ordering Product Backlog items using inputs such as value, risk, dependencies, and the Product Goal.
Topic: Artifacts, Commitments, and Done
A Scrum Team writes the Sprint Goal as: “Complete all selected Product Backlog Items.”
Which change best corrects this Sprint Goal to match the Scrum Guide’s intent?
Best answer: B
What this tests: Artifacts, Commitments, and Done
Explanation: “Complete all selected Product Backlog Items” is vague because it restates doing work rather than the purpose of the Sprint. A useful Sprint Goal is a single objective that creates coherence and guides trade-offs while Developers adapt the Sprint Backlog. Rewriting it as an outcome-focused objective restores the Sprint Goal’s role as the Sprint’s commitment.
In Scrum, the Sprint Goal is the commitment for the Sprint Backlog and answers the question of why the Sprint is valuable. When a “Sprint Goal” only says to complete the selected items, it is effectively missing because it provides no unifying objective or outcome.
A good correction is to rewrite it as a single, measurable or observable objective (an outcome), so it can:
The Sprint Goal is distinct from the Product Goal (longer-term) and from quality/validation details like the Definition of Done or acceptance criteria.
A Sprint Goal should provide a shared objective and coherence, not just restate completing the selected work.
Topic: Scrum Team and Accountabilities
Midway through a Sprint, the Developers frequently need clarification on Product Backlog items to meet the Sprint Goal. However, the Product Owner has been unavailable for days at a time and cannot be reached to answer questions or make ordering decisions. Stakeholders are starting to bypass the Product Owner and ask the Developers directly for changes.
What is the best Scrum-aligned way to mitigate this situation?
Best answer: A
What this tests: Scrum Team and Accountabilities
Explanation: An absent Product Owner is an impediment because it prevents effective Product Backlog ordering and clarification needed for empiricism and value delivery. The Scrum Master should make this transparent and work with the Product Owner and organization to restore availability and effective decision-making while preserving the Product Owner’s accountability. This prevents role confusion and stakeholder bypassing.
In Scrum, the Product Owner is accountable for maximizing value and for effective Product Backlog management, including ordering and ensuring items are understood. If the Product Owner is repeatedly unavailable, the Scrum Team’s ability to inspect and adapt and to make informed decisions is reduced, so it should be treated as an impediment.
A Scrum-aligned mitigation is for the Scrum Master to coach and facilitate changes with the Product Owner and the organization (for example, improving access, clarifying expectations, and reducing conflicting responsibilities) so the Product Owner can reliably provide decisions and clarity. Stakeholders should collaborate through the Product Owner, and the Scrum Master helps reinforce these boundaries rather than shifting Product Owner accountabilities to others.
The Product Owner must be available to fulfill their accountability, and the Scrum Master helps remove this impediment by coaching and addressing organizational causes.
Topic: Scrum Team and Accountabilities
During a Sprint, the Product Owner tells the Scrum Master: “Stakeholders are unhappy with recent priorities. From now on, a steering committee will decide the Product Backlog ordering and I’ll just publish whatever they choose.”
Which response is INCORRECT for the Scrum Master to support?
Best answer: B
What this tests: Scrum Team and Accountabilities
Explanation: In Scrum, the Product Owner may collaborate and ask others for input, but cannot delegate away accountability for ordering the Product Backlog and maximizing value. A committee can advise, but it cannot replace the Product Owner’s decision-making responsibility. The Scrum Master should reinforce this boundary while improving collaboration and transparency.
The Product Owner is accountable for maximizing the value of the product and for effective Product Backlog management, including ordering the Product Backlog. The Product Owner can involve stakeholders and Developers to gather ideas, feedback, and expertise, but accountability stays with the Product Owner.
If stakeholders want more influence, the Scrum Master should help create better transparency and feedback loops (e.g., use Sprint Reviews, clearer Product Goal, and evidence-based discussion), while coaching the Product Owner to make and communicate ordering decisions. Handing ordering to a steering committee is an anti-pattern because it transfers decision authority and weakens a single, accountable voice for value.
This shifts Product Backlog ordering decisions away from the Product Owner, who remains accountable for maximizing value and ordering the Product Backlog.
Topic: Scrum Events and Timeboxes
A Scrum Team is in the last hours of a 2-week Sprint, and the Sprint Review starts in 2 hours. The Developers say a new payment feature is “ready to show,” but it has not passed the required security tests and its release notes are incomplete. The team’s Definition of Done includes passing those security tests and completing release notes.
A key stakeholder is attending the Sprint Review and wants to decide today whether the feature can be released tomorrow.
What is the BEST next action?
Best answer: D
What this tests: Scrum Events and Timeboxes
Explanation: Because the security tests and release notes are in the Definition of Done, the feature cannot be treated as part of the Increment. The Sprint Review is the right event to make this transparent and let stakeholders inspect the current Increment and adapt the Product Backlog and release plan. Hiding incomplete work undermines empiricism and creates a false sense of progress.
An Increment is usable only when it meets the Scrum Team’s Definition of Done. If work is missing required quality steps (like security tests and release notes) it is not “Done,” even if it can be demonstrated. In the Sprint Review, the Scrum Team should be transparent about what is actually part of the Done Increment and what is still unfinished so stakeholders can inspect the current state and adapt plans.
A practical response is:
The key takeaway is to protect transparency and the integrity of “Done,” rather than adjusting timeboxes or re-labeling incomplete work.
If it does not meet the Definition of Done, it is not part of the Increment and must be made transparent so stakeholders can inspect and adapt.
Topic: Scrum Team and Accountabilities
Midway through a Sprint, several stakeholders have started attending the Daily Scrum to “check progress” and suggest changes based on what they have heard. Developers feel pressured to accept the changes immediately, and focus on the Sprint Goal is slipping.
As Scrum Master, what is the best next step to get useful stakeholder feedback without derailing the Sprint?
Best answer: D
What this tests: Scrum Team and Accountabilities
Explanation: The Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt their plan. Useful stakeholder feedback is obtained by inspecting the Increment in the Sprint Review and then adapting the Product Backlog through the Product Owner. This keeps transparency and learning high without turning the Sprint into continuous scope changes.
Stakeholders should be involved frequently, but in ways that support empiricism without disrupting the Sprint. The Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog; turning it into a stakeholder status/approval meeting undermines self-management and focus.
A practical next step is to:
If new information truly threatens the Sprint Goal, the Product Owner and Developers can renegotiate scope while keeping the Sprint Goal in mind—rather than accepting ad hoc changes during the Daily Scrum.
Stakeholder feedback is best gathered by inspecting the Increment at the Sprint Review and then adapting by updating the Product Backlog without disrupting the Developers’ Daily Scrum focus.
Topic: Scrum Team and Accountabilities
A Scrum Master is asked to “make Scrum work” because the Developers keep waiting for work assignments, the Product Owner is expected to report status and accept scope changes directly from managers, and a functional manager regularly reassigns people mid‑Sprint. The team has a clear Sprint Goal, a documented Definition of Done, and a visible Sprint Backlog.
Which underlying Scrum issue is the most likely root cause the Scrum Master should address first?
Best answer: B
What this tests: Scrum Team and Accountabilities
Explanation: The symptoms point to the organization treating Scrum roles like a traditional hierarchy: managers assign work and change scope, and Developers wait for direction. That is primarily a misunderstanding and lack of support for Scrum accountabilities and self-management. Since the Sprint Goal, Definition of Done, and visibility are already in place, the Scrum Master should focus on correcting accountability expectations and related policies.
The Scrum Master is accountable for leading, training, and coaching the organization in its Scrum adoption, including helping establish supportive policies and interactions. In this scenario, the core problem is not the presence of Scrum mechanics (there is a clear Sprint Goal, a Definition of Done, and visible artifacts), but that the organization is overriding Scrum accountabilities: managers are assigning work, changing scope directly, and reassigning people mid‑Sprint. That undermines the Developers’ self-management and the Product Owner’s accountability for ordering the Product Backlog and working with stakeholders.
A good first step is to address the organizational expectations and constraints (e.g., coaching managers and stakeholders, and changing policies that enable mid‑Sprint reassignment or direct scope injection) so the Scrum Team can operate within Scrum accountabilities.
Managers directing work and bypassing the Product Owner indicates the organization is not respecting Scrum accountabilities and self-management.
Topic: Scrum Team and Accountabilities
A Scrum Team is in a 2-week Sprint; the Sprint ends tomorrow. The Increment meets the Definition of Done and the Sprint Goal is “Enable customers to reset passwords.” Stakeholders are asking for a review of what was built so they can adjust priorities for next Sprint.
A department manager tells the Scrum Master: “Skip the Sprint Review and schedule a separate sign-off meeting next week. Also, ask the Developers to work this weekend to add two more items.”
What is the Scrum Master’s BEST next action?
Best answer: C
What this tests: Scrum Team and Accountabilities
Explanation: The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide by helping everyone understand Scrum theory and practice and by ensuring Scrum events occur as intended. In this situation, that means coaching the manager and stakeholders on the purpose of the Sprint Review and keeping the Sprint timebox intact while enabling inspection and adaptation based on the Done Increment.
Establishing Scrum as defined means the Scrum Master helps the Scrum Team and the organization understand and enact Scrum, including its roles, events, artifacts, and rules. Here, stakeholders need transparency and a chance to inspect the Done Increment and adapt the Product Backlog; that is exactly the purpose of the Sprint Review, and it must occur within the Sprint timebox. The Scrum Master should coach the manager and stakeholders away from replacing Scrum with a “sign-off” gate and away from directing Developers’ work, while supporting the Product Owner and stakeholders to collaborate in the Sprint Review. The key takeaway is to reinforce Scrum’s intended feedback loop (Review) and timeboxing, not to add control steps or change the Sprint to satisfy ad-hoc demands.
The Scrum Master is accountable for establishing Scrum as defined and ensuring its events and purpose are understood and enacted.
Topic: Scrum Events and Timeboxes
During Sprint Planning, the Product Owner presents an ordered Product Backlog and explains the desired Product Goal. The Scrum Team discusses a Sprint Goal and what can be accomplished in the upcoming Sprint.
Which statement about how Product Backlog items are selected for the Sprint is INCORRECT?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: In Sprint Planning, the whole Scrum Team collaborates to form a Sprint Goal, but Developers decide which Product Backlog items they forecast can be done. The Product Owner provides ordering, clarifies items, and works with Developers to optimize value, but does not assign items to them.
Sprint Planning results in a Sprint Goal and a plan for delivering an Increment. While the Product Owner explains objectives and the ordered Product Backlog, the selection of Product Backlog items is based on the Developers’ forecast of what they can accomplish given their capacity and the Definition of Done.
In practice:
The key boundary is that Sprint scope is not “assigned” to Developers by the Product Owner; it is collaboratively planned and forecast by the Developers.
Developers select which Product Backlog items to include in the Sprint based on their capacity and understanding, not by assignment from the Product Owner.
Topic: Scrum Team and Accountabilities
A Scrum Team’s Sprint Retrospectives have felt “useful” but quality problems keep recurring (many defects found after the Sprint). The Scrum Master changes their facilitation to help the team inspect root causes, select one improvement, and make it actionable.
Which outcome is the best evidence that the Scrum Master’s facilitation is making the Sprint Retrospective effective?
Best answer: B
What this tests: Scrum Team and Accountabilities
Explanation: An effective Sprint Retrospective results in actionable adaptation that the Scrum Team actually tries and inspects. Implementing a concrete improvement in the next Sprint and seeing a measurable quality impact provides evidence that the facilitation is enabling real improvement, not just discussion. This aligns with empiricism: transparency, inspection, and adaptation producing better outcomes.
The Scrum Master is accountable for establishing Scrum and for causing Scrum events to be effective. For the Sprint Retrospective, “effective” means the Scrum Team uses inspection to identify improvements and adapts how it works in a way that can be tried and learned from.
The strongest evidence of effective facilitation is an observable outcome after the event:
Meeting artifacts and participation can support the event, but they do not validate that the Retrospective led to real adaptation and better results.
Effectiveness is validated by an inspected-and-adapted change that measurably improves product quality in the next Sprint.
Topic: Scrum Events and Timeboxes
A Scrum Team’s stakeholders treat the Sprint Review as a sign-off gate: the Increment is shown, and a steering group must formally approve it before it is considered acceptable. If approval is not granted, the team is told to keep working on the same items until it is approved.
Which Scrum concept best corrects this misunderstanding?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: A Sprint Review is a working session where the Scrum Team and stakeholders inspect the Increment and collaborate on what to do next. Turning it into a mandatory sign-off gate undermines empiricism by replacing transparency and feedback with approval bureaucracy. The appropriate correction is to use the Sprint Review to adapt the Product Backlog based on what was learned.
In Scrum, the Sprint Review exists to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the current Increment, and stakeholders provide feedback, discuss changes in context, and collaborate on what to do next; the result is an adapted Product Backlog that improves value delivery.
Treating the Sprint Review as a sign-off gate is a common anti-pattern because it:
Quality and completeness are addressed by meeting the Definition of Done; the Sprint Review should focus on learning and next steps, not formal acceptance gates.
The Sprint Review is for collaborative inspection and adaptation, not a formal approval step that blocks progress to the next Sprint.
Topic: Artifacts, Commitments, and Done
Midway through a Sprint, the Product Owner asks to swap in two new Product Backlog Items because a stakeholder escalated. The Developers say the swap will jeopardize finishing other work, but they cannot agree on what to keep or drop and the discussion repeats every day.
Clues: the Sprint Backlog is visible and updated daily, and the team’s Definition of Done is clear and consistently met. At Sprint Planning they selected items but did not write a Sprint Goal.
What is the most likely underlying cause in Scrum terms?
Best answer: A
What this tests: Artifacts, Commitments, and Done
Explanation: The Sprint Goal provides a shared objective that enables the Product Owner and Developers to collaborate on trade-offs when new information emerges. Since there was no Sprint Goal, the team has no clear basis to decide what to change while still pursuing a coherent outcome. The other clues indicate that “Done” quality and progress transparency are not the primary issues.
The Sprint Goal is the commitment for the Sprint Backlog and is created during Sprint Planning. It gives the Scrum Team a single, shared purpose for the Sprint, which helps the Product Owner and Developers collaborate when scope needs to change: they can negotiate which Product Backlog Items to add, remove, or rework while still meeting the Sprint Goal.
In this scenario, the symptoms are repeated debate about what to keep/drop and difficulty making daily trade-offs, while transparency and the Definition of Done are explicitly strong. The missing element is the Sprint Goal, so there is no agreed “why” to anchor decisions. A clear Sprint Goal does not prevent change, but it makes change discussions faster and more coherent by focusing on value and the Sprint’s intended outcome.
Without a Sprint Goal, the Scrum Team lacks a shared objective to negotiate scope changes and collaborate on trade-offs.
Topic: Artifacts, Commitments, and Done
Mid-Sprint, several stakeholders form a “priority committee” and start re-ordering the Product Backlog directly to “ensure alignment.” The Developers report they no longer know which upcoming Product Backlog Items matter most, and Sprint Planning for the next Sprint is approaching.
Which action is most likely to create the best near-term impact on transparency and progress toward a Sprint Goal?
Best answer: D
What this tests: Artifacts, Commitments, and Done
Explanation: Ordering by committee reduces transparency because there is no single, clear ordering to inspect and use in decisions. Re-establishing the Product Owner’s accountability for ordering—while still incorporating stakeholder input—quickly creates one visible order that supports effective Sprint Planning and Sprint Goal focus. This addresses the immediate confusion without adding extra governance layers.
In Scrum, the Product Owner is accountable for maximizing value and for ordering the Product Backlog. When a committee directly re-orders items, accountability and decision-making become unclear, which immediately harms transparency: the Scrum Team cannot reliably see what is most important next.
A Scrum-aligned correction is to restore a single accountable ordering while keeping collaboration:
This most directly improves near-term clarity for upcoming Sprint Planning and strengthens focus on Sprint Goals, compared with adding approval gates, freezing ordering, or shifting ordering to Developers.
The Product Owner is accountable for Product Backlog ordering, which quickly restores a single transparent order for planning and Sprint Goal decisions.
Topic: Applying Scrum in Practice
Midway through a Sprint, the Developers discover unexpected work is needed to keep the Increment usable (a critical integration fix). At the same time, a stakeholder asks the Product Owner to add a small but urgent feature “if possible.” The Scrum Team is discussing dropping some planned Product Backlog Items and reshuffling tasks.
What should the Scrum Team clarify or verify first before deciding what to change?
Best answer: D
What this tests: Applying Scrum in Practice
Explanation: When unexpected work or new requests emerge during a Sprint, the Scrum Team should make trade-offs based on the Sprint Goal. Clarifying what outcomes the Sprint Goal requires lets the team adapt the Sprint Backlog (reorder, add, or remove work) while keeping focus on the Sprint’s purpose.
The Sprint Backlog is a plan by and for the Developers, and it can be adapted as more is learned during the Sprint. The key constraint for adapting scope and tasks is the Sprint Goal: it provides the shared purpose that guides what to keep, drop, or add.
Before deciding how to reshuffle work, the Scrum Team should inspect whether the discovered integration fix and the requested urgent feature help or hinder achieving the Sprint Goal. If meeting the Sprint Goal becomes impossible, the Product Owner can work with the Developers to negotiate scope, and only the Product Owner can cancel the Sprint.
Budget decisions, extending the timebox, or reallocating work by utilization do not provide the primary basis for Sprint Backlog adaptation in Scrum.
Scope and tasks can change, but decisions should be anchored on preserving (or renegotiating) the Sprint Goal.
Topic: Scrum Theory, Values, and Empiricism
Midway through a Sprint, an A/B test shows a recently released feature is not being used, and a different Product Backlog item (fraud detection) becomes the highest-value opportunity. The Product Owner says the Product Backlog order will not be changed until the next Sprint Review to “avoid churn.”
What is the most likely near-term impact of this decision?
Best answer: C
What this tests: Scrum Theory, Values, and Empiricism
Explanation: The Product Backlog is an emergent, ordered list that should be adapted as soon as new learning changes value, risk, or urgency. By postponing re-ordering, the Product Owner reduces transparency about what is most valuable next, which harms near-term inspection and adaptation for upcoming work.
Scrum uses empiricism, so new learning should lead to timely adaptation. The Product Backlog is continuously refined and re-ordered; when evidence changes what delivers the most value (or reduces the most risk), the Product Owner updates the ordering as soon as practical so everyone can see what is most important next.
Not re-ordering until a later event creates a near-term transparency problem: Developers and stakeholders may continue refining, discussing, or preparing for items that are no longer top priority, and the next Sprint Planning starts from an outdated view of what matters most. This does not automatically change the Definition of Done or invalidate the current Sprint Goal.
Delaying re-ordering prevents timely adaptation, making the most valuable upcoming work less transparent for refinement and Sprint Planning.
Topic: Scrum Events and Timeboxes
Mid-Sprint, during the Daily Scrum, the Developers realize a key integration approach will not work and they are now unlikely to meet the Sprint Goal unless they adjust their work. The Product Owner is not present.
What is the best next step for the Developers?
Best answer: C
What this tests: Scrum Events and Timeboxes
Explanation: The Daily Scrum exists so Developers can inspect progress toward the Sprint Goal and adapt their plan in the Sprint Backlog. When new information shows the current approach will not work, the Developers should replan immediately to improve their chance of meeting the Sprint Goal. Any deeper design or coordination can continue right after the Daily Scrum with the right people.
At the Daily Scrum, the Developers inspect where they are relative to the Sprint Goal and decide how to adjust their work for the next day. When they discover an integration approach won’t work, they should adapt by updating the Sprint Backlog (for example, changing tasks, sequencing, or swarming) so the plan reflects the new reality and maximizes the likelihood of achieving the Sprint Goal.
A common pattern is:
Delaying adaptation or inserting extra approvals reduces transparency and slows learning and delivery.
The Daily Scrum is for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, often followed by immediate collaboration to replan.
Topic: Artifacts, Commitments, and Done
Midway through a Sprint, a stakeholder asks for an urgent change. The Product Owner brings the request to the Scrum Team and asks how to handle it while still pursuing the Sprint Goal.
Which statement about the Sprint Backlog is INCORRECT?
Best answer: D
What this tests: Artifacts, Commitments, and Done
Explanation: In Scrum, the Sprint Backlog is owned by the Developers. They adapt it during the Sprint as they learn, and they may work with the Product Owner to negotiate scope in support of the Sprint Goal. No one else can unilaterally change the Developers’ plan.
The Sprint Backlog is the Developers’ plan for the Sprint: it contains the Sprint Goal, the Product Backlog Items selected for the Sprint, and a plan for delivering the Increment. Because the Developers are accountable for creating and executing that plan, they own the Sprint Backlog.
During the Sprint, the Developers adapt the Sprint Backlog as new work is discovered or assumptions change. The Product Owner can bring new information (for example, an urgent request) and collaborate with the Developers to renegotiate scope, but the Product Owner cannot simply rewrite the Sprint Backlog. The Scrum Master supports Scrum by coaching and fostering transparency, not by owning or controlling the Sprint Backlog.
Key takeaway: collaboration is expected, but unilateral changes to the Sprint Backlog by someone other than the Developers break Scrum accountabilities.
The Sprint Backlog is owned by the Developers, and changes to it are made by the Developers as they manage their plan to meet the Sprint Goal.
Topic: Applying Scrum in Practice
Which action best reflects how a Scrum Master serves the organization to help remove impediments that affect multiple Scrum Teams?
Best answer: B
What this tests: Applying Scrum in Practice
Explanation: Impediments that span multiple teams are often organizational in nature, so the Scrum Master helps by influencing the wider system. In Scrum, the Scrum Master serves the organization by leading and coaching it to increase Scrum adoption and by helping remove barriers between stakeholders and Scrum Teams. Collaborating with leaders and other Scrum Masters is an appropriate way to address cross-team impediments.
Removing impediments is part of the Scrum Master’s accountability for enabling Scrum Team effectiveness, and many impediments cannot be solved within one team. In those cases, the Scrum Master serves the organization by working beyond the team boundaries—coaching leaders and stakeholders, helping the organization understand Scrum, and collaborating with other Scrum Masters—to change policies, structures, or practices that are creating the blockage.
The key is that the Scrum Master enables removal by facilitating collaboration and organizational learning, rather than “fixing it” through command-and-control changes to people or by weakening Scrum’s timeboxes. The closest confusion is treating cross-team impediments as a Product Owner prioritization problem instead of an organizational improvement opportunity.
The Scrum Master serves the organization by leading, coaching, and collaborating to remove impediments beyond a single Scrum Team.
Topic: Scrum Events and Timeboxes
In Scrum, why is it recommended to keep Sprint length consistent, and what is a key risk when the Sprint length changes frequently?
Best answer: B
What this tests: Scrum Events and Timeboxes
Explanation: Keeping Sprint length consistent establishes a reliable cadence for planning, creating a Done Increment, and inspecting and adapting at regular intervals. When the length changes frequently, the ability to compare results over time and make predictable decisions is reduced, weakening transparency and effective inspection/adaptation.
Scrum recommends a consistent Sprint length to create a regular rhythm for the Scrum events and for delivering a Done Increment at least once per Sprint. This stable timebox improves transparency by making it easier to understand what “a Sprint’s worth” of progress and outcomes look like and to inspect results at a predictable interval.
If Sprint length changes often, it becomes harder to:
The key risk is reduced predictability and transparency, which weakens empiricism and can lead to poorer decisions about what to do next.
A consistent Sprint timebox supports empiricism through a predictable rhythm, while frequent length changes make progress and outcomes harder to inspect and adapt to.
Topic: Scrum Events and Timeboxes
Midway through a 2-week Sprint, the Scrum Team’s Sprint Goal is “Enable customers to pay with saved cards.” A stakeholder asks to add “Promo codes at checkout” for an upcoming campaign. The Developers say they could do it this Sprint only if they drop a lower-value Product Backlog item from the Sprint Backlog, and they believe the Sprint Goal could still be met.
Select TWO actions that best handle this scope change while keeping the Sprint Goal intact.
Correct answers: D, F
What this tests: Scrum Events and Timeboxes
Explanation: During a Sprint, scope may be clarified and renegotiated, but changes must not endanger the Sprint Goal. The Product Owner and Developers can collaborate to swap items in the Sprint Backlog if they can still meet the Sprint Goal. If they choose not to include the new request now, it should be added and ordered in the Product Backlog for a future Sprint.
The Sprint Goal provides focus and should remain stable throughout the Sprint. However, the Sprint Backlog is an emergent plan owned by the Developers, and its contents can be updated as more is learned. When a new request appears mid-Sprint, the Product Owner and Developers can inspect the impact and renegotiate scope (for example, swapping out lower-value work) as long as the Sprint Goal is not endangered.
If the new request is not selected for the current Sprint, the Product Owner should still make it transparent by adding it to the Product Backlog and ordering it, so it can be considered in a future Sprint based on value and urgency. The key takeaway is to manage change through transparency and negotiation without changing timeboxes or undermining the Sprint Goal.
Sprint scope can be clarified and renegotiated by the Product Owner and Developers as long as the Sprint Goal is not endangered.
If the work is not chosen for this Sprint, the Product Owner should capture and order it in the Product Backlog for later consideration.
Topic: Scrum Team and Accountabilities
Midway through a Sprint, several stakeholders ask the Scrum Master for “clear proof we are on track” and propose adding a weekly status report with percent-complete and hours spent. The Scrum Team wants to maintain transparency without adding non-Scrum bureaucracy.
Which is the best evidence/indicator to validate real progress and quality in Scrum?
Best answer: B
What this tests: Scrum Team and Accountabilities
Explanation: In Scrum, the most reliable validation of progress and quality is a usable Increment that meets the Definition of Done. It is direct evidence that work is complete to an agreed standard and can be inspected with stakeholders for feedback. This maintains transparency through the product itself rather than additional reporting layers.
Transparency in Scrum is best achieved by making the current state of the product visible and inspectable. A Done Increment is the primary evidence that the Scrum Team has produced usable value while meeting the quality bar defined by the Definition of Done. Demonstrating and discussing the Increment (for example, in the Sprint Review) enables inspection and adaptation based on stakeholder feedback without introducing extra, non-Scrum reporting bureaucracy.
Activity-based outputs (percent complete, hours spent) and proxy measures (some charts) can support conversations, but they do not validate that valuable, usable work is actually Done. The key takeaway is to communicate progress through what is working and Done, not through additional status mechanisms.
A Done Increment provides transparent, inspectable evidence of usable value and quality without extra reporting.
Topic: Artifacts, Commitments, and Done
A Scrum Team frequently finishes all selected Product Backlog Items, but after the Sprint Review the Increment needs significant rework because integration and testing were not completed. The Sprint Goal is clear and usually achieved, and the Product Owner provides clear acceptance criteria.
When asked what “Done” means, some Developers say “code complete,” while others assume “tested and integrated,” and the team has no single written agreement.
What is the most likely underlying cause in Scrum terms?
Best answer: B
What this tests: Artifacts, Commitments, and Done
Explanation: The symptoms point to inconsistent quality criteria: different Developers use different meanings of “Done,” and there is no shared, explicit agreement. In Scrum, that is a Definition of Done problem, which directly leads to incomplete Increments and predictable rework even when the Sprint Goal and acceptance criteria are clear.
In Scrum, the Definition of Done is the shared, transparent commitment for the Increment that creates a common understanding of what it means for work to be complete and usable. Here, the team meets a clear Sprint Goal and has clear acceptance criteria, yet still produces work that is not integrated and tested. The key clue is that “Done” is interpreted differently and is not written down.
A weak or missing Definition of Done causes exactly this outcome: Developers declare items complete using varying standards, so the Increment is not reliably usable at the end of the Sprint and rework emerges after inspection. The fix starts by making the Definition of Done explicit and aligned across the Scrum Team (and any organizational standards), then using it to guide planning and daily decisions.
Without a clear, shared Definition of Done, Developers apply different quality standards, creating “Done” work that still needs testing/integration and causes rework.
If you can pass several unseen mixed attempts comfortably above the target range, stop trying to memorize more questions. Schedule the real assessment while your reasoning is sharp; overtraining can turn practice into answer recognition instead of Scrum judgment.
This free set is one complete diagnostic. The PM Mastery route adds the larger practice library, focused topic drills, mixed timed mocks, progress tracking, and explanations that help you separate close Scrum answer choices instead of repeating the same public set.
Wait at least a day before retaking this page. In between, review missed explanations, reread the relevant Scrum Guide sections, and run focused drills for the weakest two topic areas.
Use the PSM I Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the PSM I guide on PMExams.com for concept review, then return here for PM Mastery practice.