Try 50 free CSM questions across the exam domains, with answers and explanations, then continue in PM Mastery.
This free full-length CSM practice exam includes 50 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 Alliance currently describes the CSM test as 50 multiple-choice questions in 60 minutes with a passing score of at least 74%. Scrum Alliance also requires approved CSM course attendance before test access. Use Scrum Alliance 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 CSM guide on PMExams.com.
Set a 60-minute timer and answer all 50 questions in one sitting. Use the explanations to mark whether each miss came from Scrum foundations, accountabilities, events, artifacts, commitments, or Scrum Master behavior.
Suggested timing checkpoints:
| Question range | Target elapsed time |
|---|---|
| 1-17 | 20 minutes |
| 18-34 | 40 minutes |
| 35-50 | 60 minutes |
| Item | Detail |
|---|---|
| Issuer | Scrum Alliance |
| Exam route | CSM |
| Official exam name | Scrum Alliance Certified ScrumMaster (CSM) |
| Full-length set on this page | 50 questions |
| Exam time | 60 minutes |
| Topic areas represented | 5 |
| Topic | Approximate official weight | Questions used |
|---|---|---|
| Scrum Foundations & Agile Mindset | 18% | 9 |
| Scrum Team & Accountabilities | 18% | 9 |
| Events & Timeboxes | 23% | 12 |
| Artifacts & Commitments | 18% | 9 |
| Scrum Master as Servant Leader | 23% | 11 |
Topic: Scrum Foundations & Agile Mindset
Midway through a 2-week Sprint, the Developers learn the third-party API version they planned to use will be shut off next week. The current Sprint Goal is still valuable, and the team believes it can be met by switching to the new API version, but that will require changing their plan and dropping some lower-priority work. The Product Owner says, “Don’t change the Sprint Backlog—we already committed to it. We’ll deal with the new API next Sprint.”
What is the best adaptation action now, according to Scrum?
Best answer: A
What this tests: Scrum Foundations & Agile Mindset
Explanation: When new learning invalidates part of the plan, Scrum expects adaptation based on inspection. The Sprint Backlog is owned by the Developers and is intentionally flexible, so they should replan and make changes transparent, collaborating with the Product Owner to optimize toward the Sprint Goal. Deferring the change would ignore current information and risk waste.
Scrum is built on empiricism: when you learn something new, you inspect and adapt as soon as practical. During a Sprint, the Sprint Backlog is the Developers’ plan for achieving the Sprint Goal, and it is meant to be emergent—updated throughout the Sprint as more is learned.
In this scenario, the new API shutdown makes part of the current plan invalid, but the Sprint Goal is still achievable by changing approach and likely adjusting scope. The right move is for the Developers to replan the Sprint Backlog and collaborate with the Product Owner on trade-offs so the work selected best supports achieving the Sprint Goal with the new information. If later the Sprint Goal becomes no longer achievable or no longer valuable, Sprint cancellation is a separate option the Product Owner can consider.
The key is adapting the plan during the Sprint instead of treating it as a fixed commitment.
The Sprint Backlog is an emergent plan, so the Developers adapt it during the Sprint in collaboration with the Product Owner to best achieve the Sprint Goal.
Topic: Scrum Team & Accountabilities
Midway through a Sprint, several stakeholders keep interrupting Developers for ad hoc progress updates and “quick checks,” which is reducing focus on completing work. The Scrum Master wants to stay transparent while directing stakeholders to the best indicator of real progress and quality.
Which evidence best validates progress in Scrum while helping reduce these interruptions?
Best answer: A
What this tests: Scrum Team & Accountabilities
Explanation: In Scrum, the primary evidence of progress is a usable Increment that meets the Definition of Done. When stakeholders can inspect a Done Increment, transparency comes from working product rather than ongoing explanations. This supports focus by reducing the need for frequent, interrupt-driven status checks.
Scrum optimizes transparency and enables inspection by making the most valuable information easy to see: a usable Increment that meets the Definition of Done. For external interruptions, pointing stakeholders to the current Done Increment (and inspecting it at appropriate times like the Sprint Review) provides objective evidence of progress and quality without relying on subjective reporting. Activity-based measures (hours, task completion percentages, volume of questions answered) can be misleading because they do not prove that value is integrated, usable, and meets quality expectations. The key takeaway is to use the Increment as the concrete basis for transparency and to protect Developers’ focus by minimizing interruption-driven status requests.
A Done Increment is the most reliable evidence of actual progress and quality that stakeholders can inspect instead of requesting constant status updates.
Topic: Events & Timeboxes
Midway through a 2-week Sprint, the Scrum Team learns of a new stakeholder decision.
Exhibit: Sprint Backlog (excerpt)
Sprint Goal: Enable checkout with stored credit cards
Selected PBIs:
- PBI-142: Save card (tokenization)
- PBI-155: Use saved card at checkout
Note: Legal says storing cards is prohibited effective immediately
Based on the exhibit, what is the best next action in Scrum?
Best answer: A
What this tests: Events & Timeboxes
Explanation: The new legal constraint makes the current Sprint Goal (stored credit cards) no longer valuable or viable, which can make it obsolete. In Scrum, only the Product Owner has the authority to cancel a Sprint. When the Sprint Goal is obsolete, cancellation is an appropriate response so a new Sprint can be planned toward a relevant goal.
Sprint cancellation is rare and is used when continuing the Sprint no longer makes sense. The key condition is that the Sprint Goal becomes obsolete, such as when market, technology, or business circumstances change so the goal is no longer valuable or feasible.
In this exhibit, “storing cards is prohibited effective immediately” directly undermines the Sprint Goal to enable checkout with stored credit cards, making the goal obsolete. In Scrum, only the Product Owner can cancel a Sprint; others can raise the concern and advise, but they cannot cancel it. After cancellation, the Scrum Team can re-evaluate the Product Backlog and plan a new Sprint around an updated goal.
Only the Product Owner can cancel a Sprint, and cancellation is appropriate when the Sprint Goal becomes obsolete.
Topic: Scrum Foundations & Agile Mindset
A Scrum Team is building a brand-new customer onboarding experience. Stakeholders agree the current process is broken, but they cannot describe a complete solution up front, and feedback on early versions keeps changing what “good” looks like. Which Scrum concept best matches an appropriate response to this kind of complex problem?
Best answer: D
What this tests: Scrum Foundations & Agile Mindset
Explanation: The situation shows complexity: the path to a good solution is discovered through learning and feedback, not through upfront analysis. Scrum addresses complex work with empiricism—frequent inspection and adaptation. The Sprint Review is the event specifically designed to inspect the Increment with stakeholders and adapt the Product Backlog based on what emerges.
A key sign of a complex problem is that both the solution and the best way forward are uncertain and will change as you learn (cause and effect can only be understood in hindsight). In Scrum, the appropriate response is to shorten feedback loops and use empiricism (transparency, inspection, adaptation) rather than relying on a detailed predictive plan.
The Sprint Review is where the Scrum Team and stakeholders inspect the Increment, discuss what was learned, and adapt the Product Backlog to reflect new insights. This is the primary Scrum mechanism for leveraging changing stakeholder understanding and market feedback to steer the product toward better outcomes.
It enables frequent inspection of the Increment with stakeholders and adaptation of the Product Backlog based on what is learned.
Topic: Artifacts & Commitments
A Scrum Team’s Product Backlog contains about 200 items. Refinement sessions have grown to 6 hours per week, mostly spent writing detailed acceptance criteria and estimates for items unlikely to be worked on for months. Stakeholders complain that progress is slowing.
Which action is something the Scrum Team SHOULD AVOID to keep refinement “just enough” and reduce waste?
Best answer: D
What this tests: Artifacts & Commitments
Explanation: Product Backlog refinement should be just enough to support ordering and near-term selection, not an attempt to fully specify the whole product. Detail and estimates are most valuable close to when the work may be done because knowledge changes. Avoid practices that create large amounts of speculative “ready” inventory and rework.
Product Backlog refinement is an ongoing activity to add detail, estimates, and order to Product Backlog items, but it is not intended to fully define all future work. When refinement spends significant time detailing items that are unlikely to be selected soon, it becomes waste: assumptions expire, stakeholders change their minds, and the team pays rework costs.
A “just enough” approach typically means:
The key is to optimize for learning and delivery, not for exhaustive up-front specification.
Over-refining far-future items creates inventory and rework, reducing time for delivering valuable Increments.
Topic: Scrum Master as Servant Leader
A Scrum Team is building an internal customer portal. The organization has announced a new strategic objective (OKR) to “reduce call-center volume by 20% this quarter.” Stakeholders ask the Scrum Team for a detailed monthly alignment document that traces every requirement to the OKR.
As Scrum Master, which approach best aligns the team’s work to organizational strategy while keeping documentation lightweight and useful?
Best answer: C
What this tests: Scrum Master as Servant Leader
Explanation: Use Scrum’s existing goals and artifacts to make strategy alignment transparent. A Product Goal aligned to the OKR, plus an ordered Product Backlog that expresses what delivers that goal, provides a single, lightweight source of truth. It can be inspected in events like Sprint Review and adapted without creating heavy, parallel documentation.
In Scrum, alignment to organizational strategy is best achieved by making the Product Goal explicit and ensuring the Product Backlog is ordered to maximize progress toward that goal. The Scrum Master can facilitate stakeholder collaboration with the Product Owner so the strategic objective is translated into a clear Product Goal and reflected in ordering and refinement.
This keeps documentation lightweight because:
Creating separate traceability documents or approval gates often duplicates the Product Backlog and reduces agility without improving transparency.
The Product Goal and ordered Product Backlog provide lightweight, transparent alignment to strategy and can be inspected and adapted each Sprint.
Topic: Scrum Team & Accountabilities
During the Sprint, the Daily Scrum has drifted into a 15-minute status meeting where the Product Owner asks each Developer for an update and assigns “today’s tasks.” The Developers mostly report progress to the Product Owner instead of planning their work.
Which Scrum concept best matches the Scrum Master’s next response?
Best answer: B
What this tests: Scrum Team & Accountabilities
Explanation: The Daily Scrum is a Developers’ event used to inspect progress toward the Sprint Goal and adapt the plan in the Sprint Backlog. When it becomes a status meeting or turns into task assignment, the Scrum Master serves by coaching and facilitating a return to its purpose. That restores empiricism and self-management without changing Scrum’s roles or events.
In Scrum, the Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt their plan for the next day of work. When it is misused as a status meeting led by someone else (such as the Product Owner) or as a task-assignment session, transparency may increase for observers but the Developers lose ownership of planning and self-management.
A Scrum Master’s servant-leader response is to help the Scrum Team understand and enact Scrum by coaching the Developers on:
The key is restoring the event’s purpose rather than relocating it or having someone else “run” it.
The Daily Scrum is for the Developers to plan the next 24 hours toward the Sprint Goal, and the Scrum Master helps them understand and enact this.
Topic: Events & Timeboxes
At the end of the Sprint, the Product Owner says the Sprint Review will be a slide deck “status update” followed by stakeholders signing a document to accept the work. A few Developers mention they are not planning to demonstrate anything.
As Scrum Master, what is the most important thing to verify or ask first before deciding how to correct this Sprint Review approach?
Best answer: D
What this tests: Events & Timeboxes
Explanation: The Sprint Review is for inspecting the Increment and collaborating on what to do next. Before addressing the slide-deck and sign-off anti-patterns, first confirm there is a usable Increment that meets the Definition of Done and can be inspected with stakeholders. If there is no Done Increment to inspect, changing the meeting format alone won’t fix the underlying problem.
A Sprint Review’s purpose is to inspect the outcome of the Sprint (the Increment) and adapt the Product Backlog based on feedback and what was learned. “Status update” slides and formal sign-off are common anti-patterns because they shift the event away from product inspection and collaborative next-step decisions.
The first thing to verify is whether a usable Increment exists that meets the Definition of Done and can be demonstrated/inspected. If the work is not Done, the immediate correction is to restore transparency about what is actually Done, inspect only what meets the DoD, and use the discussion to adapt the Product Backlog rather than seeking acceptance paperwork. Once a Done Increment is available, you can then coach toward an interactive review centered on the Increment and future options.
Without a Done Increment to inspect, the Sprint Review cannot meet its purpose and will easily devolve into status reporting or sign-off.
Topic: Scrum Team & Accountabilities
Two days before the end of a 2-week Sprint, the Scrum Team reviews the Sprint Backlog.
Exhibit: Sprint Backlog + Definition of Done (excerpt)
Sprint Goal: Enable customers to manage account access
PBIs:
- Password reset flow | Done
- Update profile email | In progress
- Add admin audit log | Not started
DoD (excerpt): Code reviewed, automated tests pass,
security review completed, integrated on main branch
Based on the exhibit, what is the best next action to fulfill the Scrum Team’s responsibility each Sprint?
Best answer: D
What this tests: Scrum Team & Accountabilities
Explanation: The Scrum Team is accountable for creating a valuable, useful Increment every Sprint, which means work must meet the Definition of Done and be integrated. The exhibit shows at least one item is not done to the DoD because security review and integration are required. The best action is to focus the team on finishing done-quality work so a usable Increment exists.
In Scrum, the Scrum Team is accountable for creating a valuable, useful Increment each Sprint, and an Increment is only usable when it meets the Definition of Done and is integrated. The exhibit’s DoD explicitly requires security review and integration to the main branch, so any work missing those elements is not part of the Increment yet. With limited time left, the team should adapt its plan and concentrate effort on completing work to the DoD so the Sprint produces a usable Increment that supports the Sprint Goal.
This preserves quality and usability rather than redefining “Done” to fit the calendar.
A valuable, useful Increment requires work that meets the Definition of Done and is integrated, so the team should focus on finishing Done work.
Topic: Artifacts & Commitments
During Product Backlog refinement, the Scrum Team discusses a Product Backlog item: “Enable customers to download a monthly usage report.” The Developers say it is too large and unclear to complete within one Sprint. The Product Owner still wants value delivered next Sprint.
As the Scrum Master, what is the best next step?
Best answer: A
What this tests: Artifacts & Commitments
Explanation: Refinement is the right time to reduce uncertainty and right-size work so it is ready for possible selection. The best next step is to split the item into thin vertical slices that each produce a usable Increment toward the Product Goal, with clear acceptance criteria so the Developers can forecast and plan effectively.
When a Product Backlog item is too large or unclear, the Scrum Team adapts the Product Backlog through refinement so it can be completed within a Sprint and still deliver value. The key is vertical slicing: each new item represents a small, end-to-end piece of functionality that a user can benefit from (not a technical layer).
A practical sequence in refinement is:
Horizontal task breakdown and escalation can happen later if needed, but they don’t by themselves create small, independently valuable backlog items.
Vertical slices create smaller Product Backlog items that each deliver usable customer value and can be completed within a Sprint.
Topic: Scrum Master as Servant Leader
Midway through a Sprint, two Developers are in a heated disagreement about a technical approach. The tension is spilling into the Daily Scrum, and other Developers are avoiding the discussion. As the Scrum Master, you want to resolve the conflict and improve collaboration.
Which action should you NOT take?
Best answer: C
What this tests: Scrum Master as Servant Leader
Explanation: The Scrum Master serves the Scrum Team by facilitating constructive conflict resolution while preserving the team’s self-management. Bringing in a manager to decide the outcome shifts accountability away from the Developers and typically reduces openness and commitment. The better approach is to help the team inspect options and agree on how they will decide and work together.
In Scrum, conflict is often a sign of complex work and differing assumptions; the Scrum Master’s job is to help the Scrum Team address it through facilitation and coaching, not by substituting authority. Because Developers are accountable for creating the Increment, they need to self-manage their technical decisions and collaboration.
Helpful facilitation moves include:
Handing the decision to an external manager undermines self-management and usually suppresses the collaboration the team needs to build.
Escalating to a manager to decide removes ownership from the self-managing Scrum Team and avoids facilitating the team’s collaboration.
Topic: Scrum Team & Accountabilities
A Scrum Team treats refinement as a formal approval step: during a mid‑Sprint meeting, Developers walk through upcoming Product Backlog items and ask the Product Owner to “sign off” each item before they will consider it for a future Sprint. The Scrum Master wants to redirect them to the Scrum concept that clarifies work through collaboration without becoming a gate.
Which Scrum concept best matches what the Scrum Master should coach them toward?
Best answer: B
What this tests: Scrum Team & Accountabilities
Explanation: The described meeting is trying to clarify upcoming work, which is exactly what Product Backlog refinement is for. In Scrum, refinement is a collaborative activity between the Product Owner and Developers to improve shared understanding and readiness for future selection, not a formal approval or stage-gate. Clarity emerges through conversation and ongoing learning.
The core concept is Product Backlog refinement: an ongoing activity where the Product Owner and Developers collaborate to add detail, estimates, and order to Product Backlog items as needed. Its purpose is to create enough shared understanding so the Scrum Team can make good choices in Sprint Planning and adapt as they learn.
Turning refinement into “sign-off” creates a false handoff and implies requirements are fixed, which conflicts with empiricism and reduces collaboration. In Scrum, commitment happens through selecting work into the Sprint Backlog and aligning on a Sprint Goal, while quality is ensured by meeting the Definition of Done and inspecting the Increment at Sprint Review.
Refinement should improve clarity and options, not function as an approval gate.
Refinement is an ongoing, collaborative activity to add clarity and order to Product Backlog items, not a sign-off gate.
Topic: Scrum Foundations & Agile Mindset
A stakeholder asks, “Who is responsible for deciding what to build next, ordering the work, and maximizing the product’s value?”
Which role best matches this responsibility in Scrum?
Best answer: D
What this tests: Scrum Foundations & Agile Mindset
Explanation: In Scrum, value and “what to build next” decisions are owned by the Product Owner. This accountability includes ordering the Product Backlog to meet the Product Goal and optimize outcomes. While a project manager may perform similar work in traditional settings, that role is not a Scrum accountability.
Scrum distributes responsibilities that are often centralized in traditional project management. The Product Owner is accountable for maximizing the value of the product, which is expressed through clear product decisions and an ordered Product Backlog. When someone asks who decides the next most valuable work, the Scrum answer is the Product Owner (not a separate project manager role). The Scrum Master focuses on enabling effective Scrum and removing impediments, and Developers focus on creating a usable Increment each Sprint. The key distinction is that “what and why” are product/value decisions owned by the Product Owner, while “how” is owned by Developers, supported by the Scrum Master.
The Product Owner is accountable for maximizing value, including ordering the Product Backlog and making product decisions.
Topic: Events & Timeboxes
Midway through a 2-week Sprint, the 15-minute Daily Scrum has drifted into a 25-minute round-robin where each Developer reports status to the Product Owner while a stakeholder asks for progress details. Little time is spent adjusting the plan to meet the Sprint Goal, and testing work needed to meet the Definition of Done is being “left for later.”
As Scrum Master, what is the BEST next action?
Best answer: C
What this tests: Events & Timeboxes
Explanation: The Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog by creating a plan for the next day of work. When it becomes a status meeting for the Product Owner or stakeholders, the intervention is to refocus it on daily planning, keep the 15-minute timebox, and take detailed discussions and stakeholder Q&A outside the event.
In Scrum, the Daily Scrum is a 15-minute event for the Developers to plan their work for the next 24 hours by inspecting progress toward the Sprint Goal and adapting the Sprint Backlog. When people start “reporting out” to the Product Owner or stakeholders, the event loses its purpose and often expands beyond its timebox.
A practical intervention is to help the Developers:
Stakeholders can get updates via the Product Owner and at the Sprint Review; the Daily Scrum should remain optimized for Developers’ daily planning.
This restores the Daily Scrum as Developers’ daily planning toward the Sprint Goal while protecting the 15-minute timebox and keeping non-Developers from turning it into a status meeting.
Topic: Scrum Master as Servant Leader
A Scrum Team is two weeks into a product. In each Sprint they complete “analysis,” “design,” or “build” work, but testing and integration are deferred to the end of a planned 3-month release, so Sprint Reviews show documents and partially built components instead of a usable Increment.
As the Scrum Master, what is the best next step to restore incremental delivery?
Best answer: D
What this tests: Scrum Master as Servant Leader
Explanation: This is a “waterfall in Sprints” anti-pattern: work is batched by phase and the Increment is not integrated and Done each Sprint. The best next step is to use Scrum’s inspection and adaptation to change how the team works so each Sprint produces a usable, Done Increment by integrating and testing within the Sprint.
When Sprints are used as mini-phases (analysis Sprint, design Sprint, build Sprint) and integration/testing is deferred, the team loses empiricism because the Sprint Review cannot inspect a potentially releasable Increment. The Scrum Master’s next step is to make the problem visible and help the Scrum Team adapt its way of working so value is delivered incrementally.
Practical changes to drive in/after the Retrospective include:
Organizational escalation or changing timeboxes may be needed later, but the immediate lever is enabling the team to adapt its workflow to produce a Done Increment every Sprint.
This directly addresses the “waterfall in Sprints” pattern by enabling inspection/adaptation of how work is sliced and finished to meet the Definition of Done every Sprint.
Topic: Scrum Master as Servant Leader
Midway through a 2-week Sprint, a security stakeholder messages two Developers directly: “We need account lockout by Friday for an audit—please add it now.” The Sprint Goal is “Customers can reset their password.” The stakeholder also suggests “skip some automated tests to save time,” even though the Definition of Done requires automated tests and peer review.
As Scrum Master, what is the BEST next action?
Best answer: C
What this tests: Scrum Master as Servant Leader
Explanation: When stakeholders bypass the Product Owner to change work mid-Sprint, the Scrum Master should re-establish the right collaboration path: make the request transparent and involve the Product Owner and Developers. The Product Owner decides what to pursue, while Developers evaluate feasibility and adjust the Sprint Backlog as needed. Any adaptation must still meet the Sprint Goal and the Definition of Done.
In Scrum, stakeholders can and should share information with the Scrum Team, but changing what the team works on during the Sprint must be handled through the Product Owner’s ordering decisions and the Developers’ plan for the Sprint (the Sprint Backlog). As Scrum Master, your servant-leadership move is to surface the request immediately, bring the Product Owner into the conversation, and enable the Developers to inspect the impact on the Sprint Goal and their capacity. If the request can be accommodated without undermining the Sprint Goal, the Developers can renegotiate the Sprint Backlog with the Product Owner. The suggestion to “skip tests” is a direct threat to the Definition of Done and should not be accepted.
Key takeaway: enable fast inspection and adaptation through the right accountabilities—not by letting stakeholders directly replan the Sprint or by lowering quality standards.
It restores the Product Owner’s accountability for ordering and allows inspection/adaptation without compromising the Sprint Goal or the Definition of Done.
Topic: Scrum Master as Servant Leader
In Scrum, what is the best evidence that a completed Increment is usable and potentially releasable at the end of a Sprint?
Best answer: A
What this tests: Scrum Master as Servant Leader
Explanation: A Done Increment is usable and potentially releasable when it meets the Scrum Team’s Definition of Done. The Definition of Done creates transparency about the quality and completeness required for work to be considered “Done.” If that standard is met, the Increment is in a releasable state regardless of other outcomes.
The core evidence for a usable, potentially releasable Increment is that it meets the Definition of Done. The Definition of Done is the shared, transparent quality bar for the Increment; it tells everyone what it means for work to be complete to a level that supports use and release. Meeting acceptance criteria can indicate a specific Product Backlog item behaves as expected, but it does not replace the broader, cross-cutting quality expectations captured in the Definition of Done (e.g., integration, testing, documentation, security). Similarly, achieving the Sprint Goal describes the Sprint’s outcome, not whether the Increment meets the required quality to be releasable.
Only an Increment that meets the Scrum Team’s Definition of Done is considered usable and potentially releasable.
Topic: Scrum Team & Accountabilities
A Product Owner is new and tells the team that a business analyst will “own the requirements” and order the Product Backlog, while an executive sponsor will give final priority decisions when needed. During Sprint Planning, Developers ask which of two top items should be selected to best support the Sprint Goal, and the business analyst says the sponsor will decide after the Sprint starts.
What is the most likely near-term impact?
Best answer: B
What this tests: Scrum Team & Accountabilities
Explanation: The Product Owner is accountable for maximizing value and ordering the Product Backlog. When that accountability is effectively shifted to a business analyst and sponsor, the Scrum Team loses a clear single decision-maker. The near-term result is reduced transparency and delayed decisions that directly threaten Sprint Goal alignment and progress.
In Scrum, the Product Owner is the one accountable for Product Backlog management, including making ordering decisions to maximize value. A business analyst or sponsor can contribute ideas, analysis, and feedback, but they do not replace the Product Owner’s accountability.
When ordering and priority decisions are deferred to someone outside the Scrum Team (or split across multiple people), Developers cannot reliably inspect current priorities during Sprint Planning or adapt quickly during the Sprint. This creates immediate ambiguity about what best supports the Sprint Goal, increasing delays, rework, and churn in the Sprint Backlog. The key takeaway is that input can be delegated, but Product Owner accountability for value and backlog ordering cannot.
Without a single accountable Product Owner making ordering decisions, priorities become unclear, slowing selection and progress toward the Sprint Goal.
Topic: Events & Timeboxes
In Scrum, what is the primary purpose of the Sprint, and how does it support predictability?
Best answer: A
What this tests: Events & Timeboxes
Explanation: The Sprint is Scrum’s core timebox and container event where a usable, Done Increment is created. By repeating Sprints with a consistent cadence of one month or less, Scrum ensures frequent opportunities to inspect outcomes and adapt plans. This regular feedback loop supports predictability in delivering value.
The Sprint is a fixed-length event (one month or less) that contains all other Scrum events and results in a valuable, useful Increment that meets the Definition of Done. Its purpose is to create a regular cadence where progress toward the Product Goal can be inspected and plans can be adapted based on what was learned. Because inspection and adaptation happen frequently (at least once each Sprint), stakeholders and the Scrum Team get timely feedback, reducing risk and improving the ability to forecast and make informed decisions. The Sprint is not intended to freeze scope; it provides focus via the Sprint Goal while still allowing clarification and negotiation within the Sprint as long as the Sprint Goal remains intact.
The Sprint is the container event that produces a Done Increment and creates a regular cadence for frequent inspection and adaptation, improving predictability.
Topic: Events & Timeboxes
It is Day 6 of a 10-day Sprint. The Sprint Goal is “Customers can reset their password.” The Definition of Done requires automated regression tests to pass.
In today’s 15-minute Daily Scrum, the Developers discover a failing regression test and estimate they will not meet the Sprint Goal unless they spend time fixing it. A stakeholder also asks the Product Owner to add “change email address” before the Sprint ends.
What is the BEST next action regarding the Sprint Backlog?
Best answer: C
What this tests: Events & Timeboxes
Explanation: The Sprint Backlog is a plan by and for the Developers, and it is adapted as they inspect progress each day. Discovering failing tests is new information that requires immediate replanning to still achieve the Sprint Goal and satisfy the Definition of Done. The right response is to update the Sprint Backlog to reflect the next best plan of work.
In the Daily Scrum, the Developers inspect progress toward the Sprint Goal and adapt their plan for the next day of work. That adaptation is made visible by updating the Sprint Backlog (for example, adding or changing Sprint Backlog items such as tasks, adjusting sequencing, and refining the plan).
Because the Definition of Done requires passing regression tests, fixing the failing test is necessary work to produce a usable Increment. Stakeholder pressure for extra scope does not override the Sprint Goal; if meeting the Sprint Goal is at risk, the Developers should update the Sprint Backlog to reflect the best plan and then collaborate with the Product Owner about any needed trade-offs.
Waiting to update the plan reduces transparency and delays adaptation.
After daily inspection, Developers adapt the Sprint Backlog by updating the plan and work needed to achieve the Sprint Goal while meeting the Definition of Done.
Topic: Artifacts & Commitments
A Scrum Team is in a 2-week Sprint. The Sprint ends today and the Sprint Review starts in 1 hour. A stakeholder is pressuring the team to demo a new reporting feature, but the Developers say the automated tests and security checks in the Definition of Done are not complete for that Product Backlog item.
What is the Scrum Master’s BEST next action?
Best answer: B
What this tests: Artifacts & Commitments
Explanation: An Increment is the sum of all Product Backlog items completed during a Sprint (and previous Increments) that meet the Definition of Done and are usable. If the reporting feature does not meet the Definition of Done, it is not part of the Increment and should not be represented as one at the Sprint Review. Transparency is maintained by showing what is actually Done and adapting the Product Backlog for what remains.
In Scrum, an Increment is a concrete step toward the Product Goal that is in a usable condition and meets the Definition of Done. It is formed by adding together all Product Backlog items that were completed during the Sprint (plus prior Increments), integrated so the result is valuable and potentially releasable.
In this scenario, the reporting feature has not met the Definition of Done because required tests and security checks are incomplete. That means it is not part of the Increment, regardless of stakeholder pressure or the desire to “preview” it. The Scrum Master should help uphold Scrum by enabling transparency: present what is truly Done at the Sprint Review and ensure the incomplete Product Backlog item is returned to the Product Backlog for future ordering and completion.
Only Product Backlog items completed to the Definition of Done are part of the Increment; unfinished work is not an Increment and should be re-ordered in the Product Backlog.
Topic: Artifacts & Commitments
A Scrum Team is building a customer portal. After several Sprint Reviews, stakeholders have new feedback and competitors released similar features. The Product Owner says, “Let’s finalize the Product Backlog for the next 6 months so it stops changing.”
Which statement about maintaining the Product Backlog is INCORRECT?
Best answer: C
What this tests: Artifacts & Commitments
Explanation: The Product Backlog is a living, emergent artifact that evolves with new information, feedback, and changes in the environment. Maintaining it means continually adding, removing, and re-ordering items to maximize value toward the Product Goal. Freezing it for a fixed period reduces adaptability and undermines empiricism.
In Scrum, the Product Backlog is never complete because products exist in changing contexts and the Scrum Team learns continuously through inspection at events like the Sprint Review. As knowledge, opportunities, risks, and stakeholder needs change, the Product Backlog must be updated to reflect the best current understanding of what to do next to achieve the Product Goal.
Good maintenance practices include:
Freezing the Product Backlog treats it like a fixed plan instead of an emergent artifact used to adapt as learning occurs.
Freezing the Product Backlog contradicts that it is emergent and continually updated as learning occurs.
Topic: Events & Timeboxes
At the end of each Sprint, the Product Owner runs a 60-minute Sprint Review where they present a slide deck of completed Product Backlog Items and ask stakeholders to “approve the Sprint.” The Developers are not asked to demonstrate the Increment, even though it meets the Definition of Done and is available in a test environment. Little feedback is gathered and the Product Backlog is not adjusted.
What is the most likely underlying cause in Scrum terms?
Best answer: C
What this tests: Events & Timeboxes
Explanation: A Sprint Review is for the Scrum Team and stakeholders to inspect the Increment together and adapt what to do next in the Product Backlog. A slide-deck “approval” meeting replaces direct inspection of the Increment and prevents meaningful collaboration. The core issue is event misuse driven by a sign-off/status mindset, not the lack of a Done Increment.
The Sprint Review’s purpose is to inspect the outcome of the Sprint (the Increment) and collaboratively determine future adaptations to the Product Backlog. In the scenario, a slide deck and “approve the Sprint” language indicate the event has been turned into a phase-gate/status report, even though a Done Increment is available to demonstrate. That misuse reduces transparency (stakeholders can’t truly inspect) and blocks inspection and adaptation (little feedback, no Product Backlog adjustment).
A correction is to reframe the Review as a working session:
The key signal is not the format (slides), but the replacement of product inspection and backlog adaptation with sign-off.
The symptoms point to misunderstanding the Sprint Review’s purpose: collaboratively inspect the Increment and adapt the Product Backlog with stakeholders.
Topic: Events & Timeboxes
Midway through a 2-week Sprint, the Developers notice they are losing about 2 hours per day resolving merge conflicts. This is starting to put the Sprint Goal at risk. The team believes a small change to how they integrate work (something fully within the Scrum Team’s control) could reduce the conflicts immediately.
What is the best next step?
Best answer: B
What this tests: Events & Timeboxes
Explanation: Scrum allows continuous improvement at any time, not only in the Sprint Retrospective. When an improvement is within the Developers’ control and helps achieve the Sprint Goal, they can adapt their plan during the Sprint by updating the Sprint Backlog. The Retrospective remains the dedicated event to inspect how the Sprint went and plan further improvements.
Continuous improvement is not restricted to the Sprint Retrospective. During a Sprint, the Developers can adapt their plan (the Sprint Backlog) whenever they learn something that affects their ability to meet the Sprint Goal.
In this scenario, merge conflicts are actively harming progress, and the team has an immediately actionable improvement within its control. The best sequence is:
Deferring all improvement until the Retrospective delays adaptation, while pausing the Sprint or escalating to management bypasses the Scrum Team’s ability to self-manage.
Continuous improvement can be applied anytime, and the Developers can adapt their plan during the Sprint to protect progress toward the Sprint Goal.
Topic: Events & Timeboxes
A Scrum Team suggests changing their cadence to an 8-week cycle so they can “do fewer ceremonies.” The Scrum Master explains that this would reduce how often stakeholders can inspect progress and would increase the risk of building the wrong thing.
Which Scrum concept is the Scrum Master referring to?
Best answer: D
What this tests: Events & Timeboxes
Explanation: The Sprint is the event that sets the regular cadence for delivering a Done Increment and getting stakeholder feedback. Scrum limits a Sprint to one month or less; shortening the Sprint generally increases opportunities for inspection and adaptation. Lengthening it generally delays feedback and increases the risk of building the wrong product.
In Scrum, the Sprint is a fixed-length event that contains all other events and produces at least one usable Increment. The Scrum Guide timeboxes a Sprint to one month or less to keep risk and complexity manageable.
Sprint length directly affects empiricism:
Changing ceremony frequency is not the purpose of the Sprint timebox; the key reason is enabling frequent feedback while reducing risk.
A Sprint is timeboxed to one month or less, and longer Sprints reduce feedback frequency and increase risk.
Topic: Artifacts & Commitments
Midway through a Sprint, the Scrum Team has finished a high-priority security fix and integrated it into the existing product. The Developers say the updated Increment meets the team’s Definition of Done, and it is usable.
A stakeholder asks the Product Owner to release the fix to customers today. The Product Owner hesitates, saying, “We usually release after the Sprint Review.”
What is the best next step?
Best answer: C
What this tests: Artifacts & Commitments
Explanation: An Increment is only release-ready when it is usable and meets the Definition of Done. If that condition is satisfied, it may be released at any time, including during a Sprint. The Product Owner is accountable for deciding whether and when to release value.
Release readiness in Scrum depends on the Increment being usable and meeting the Definition of Done (DoD). When those conditions are true, the Increment can be released at any time; Scrum does not require waiting for the Sprint Review. The Sprint Review is for inspecting the outcome of the Sprint with stakeholders and adapting the Product Backlog, not for “approval” gates.
A practical sequence is:
Waiting for an event, bypassing the DoD, or escalating for an exception undermines transparency and quality.
A usable Increment that meets the Definition of Done can be released at any time, and release timing is a Product Owner decision.
Topic: Artifacts & Commitments
A Product Owner inherited a Product Backlog where items planned for “six months from now” have detailed acceptance criteria and UI mockups, but the items likely to be selected for the next Sprint are large and vague. The Developers say Sprint Planning has become slow because they can’t understand near-term work well enough to forecast.
As Scrum Master, what is the best next step?
Best answer: A
What this tests: Artifacts & Commitments
Explanation: Product Backlog items should have more detail as they get closer to implementation, while distant items remain less detailed because learning will change them. The fastest way to improve Sprint Planning here is to refine and clarify the items most likely to be selected soon, with the Product Owner and Developers collaborating.
In Scrum, the Product Backlog is emergent and its items vary in detail over time. Items that are likely to be selected in the near term need enough shared understanding (and often sizing/splitting) so the Developers can create a workable Sprint Backlog and forecast during Sprint Planning. Items far from being worked on should generally stay higher level, because detailed specification too early creates waste when priorities and understanding change.
A good next step is to facilitate Product Backlog refinement that rebalances detail: increase clarity and reduce size for the next 1–2 Sprints’ candidates, and avoid over-investing in distant items. The takeaway is to align item detail with time horizon to support empiricism and effective planning.
Near-term items should be the most detailed so the Scrum Team can select them confidently in Sprint Planning.
Topic: Scrum Foundations & Agile Mindset
A functional manager asks the Scrum Master for a list of tasks for the Sprint and says they will assign each task to specific people to ensure accountability.
In Scrum, who should decide how to organize and assign the work needed to meet the Sprint Goal?
Best answer: B
What this tests: Scrum Foundations & Agile Mindset
Explanation: In Scrum, the Developers are accountable for creating the Increment and self-manage how they will accomplish the work. That includes organizing the Sprint Backlog work and deciding who does what to achieve the Sprint Goal. External managers and stakeholders can provide input, but they do not direct the Developers’ day-to-day work decisions.
Scrum relies on self-managing Scrum Teams. While stakeholders and managers may influence outcomes through goals, constraints, and feedback, decisions about how to turn Product Backlog Items into a usable Increment are made within the Scrum Team.
In this situation, the decision being pushed outside is task assignment and work organization during the Sprint. In Scrum, that is part of the Developers’ self-management because they are the ones doing the work and are accountable for meeting the Definition of Done and delivering value each Sprint. The Scrum Master helps the organization understand and respect these boundaries, rather than enabling command-and-control assignment.
A Product Owner decides ordering of the Product Backlog, not who does tasks.
Developers self-manage by deciding how to do the work and who does what to meet the Sprint Goal.
Topic: Artifacts & Commitments
Midway through a Sprint, Developers are finishing several Product Backlog Items (API endpoints, UI screens, and a database change). Each item is marked “Done” when the code is complete, but integration happens only at the end of the Sprint, and the pieces often don’t work together.
Which approach best supports creating multiple Increments during the Sprint and combining them into a cohesive whole?
Best answer: A
What this tests: Artifacts & Commitments
Explanation: Scrum allows multiple Increments to be created within a Sprint, but each Increment must meet the shared Definition of Done. If “Done” excludes integration, the team is producing partial work that cannot reliably add up to a usable whole. Expanding the Definition of Done to include integration and verifying it continuously enables cohesive accumulation throughout the Sprint.
Multiple Increments can be created during a Sprint as Developers complete work on Product Backlog Items. The key is that every Increment is a concrete, usable step forward and must meet the Scrum Team’s shared Definition of Done. When integration is deferred until the end, “Done” becomes ambiguous and the Increments don’t reliably combine.
A Scrum-aligned way to make the Increments add up is to:
This avoids discovering incompatibilities late and keeps the evolving product usable at all times.
Each Increment must meet a shared Definition of Done, so including integration enables multiple Increments to accumulate into one cohesive Increment during the Sprint.
Topic: Scrum Foundations & Agile Mindset
A Scrum Team is building a new customer-facing recommendation feature. Even after analysis, the team cannot predict which approach will work; stakeholder feedback from each Sprint Review frequently changes what “good” looks like and causes rework.
Which response is most Scrum-aligned for this kind of problem?
Best answer: D
What this tests: Scrum Foundations & Agile Mindset
Explanation: Unpredictable outcomes and changing understanding based on real feedback are signs of a complex problem. Scrum’s response is empiricism: deliver small increments frequently, inspect results with stakeholders, and adapt the Product Backlog and next steps based on what is learned.
The key signal of complexity is that cause-and-effect can’t be reliably determined up front: even with expertise and analysis, the “right” solution emerges only after trying something and observing results. In the scenario, repeated learning at Sprint Reviews changes what stakeholders value, so the work benefits from tight feedback loops.
A Scrum-aligned response is to:
Up-front baselining and expert-driven decisions fit “complicated” work better, where analysis can predict outcomes.
When outcomes are unpredictable and feedback changes direction, Scrum uses short feedback loops to learn and adapt through increments.
Topic: Events & Timeboxes
During the Sprint Retrospective, the Scrum Team generates 18 improvement ideas. The Developers say they can realistically implement only a small amount of improvement work in the next Sprint without risking the Sprint Goal.
The Scrum Master wants the team to choose a small number of high-impact actions and be able to inspect progress during the Sprint. What should the Scrum Team do next?
Best answer: A
What this tests: Events & Timeboxes
Explanation: To maximize impact without jeopardizing the Sprint Goal, the team should pick only a small number of concrete improvements they can realistically complete next Sprint. Making those actions visible in the Sprint Backlog supports transparency. Inspecting progress frequently (for example, in the Daily Scrum) helps the team adapt quickly if the improvements are not happening.
A Sprint Retrospective should produce actionable improvements, but trying to do too many at once reduces focus and predictability. The Scrum Team should select a small number of high-impact changes they can complete in the next Sprint, then make those actions transparent and inspectable.
A practical way is to:
This optimizes learning and continuous improvement while respecting the Sprint timebox and protecting the Sprint Goal; tracking outside Scrum artifacts or expanding meetings tends to reduce transparency and focus.
This keeps the improvements small and actionable, makes them transparent in the Sprint Backlog, and enables frequent inspection and adaptation during the Sprint.
Topic: Scrum Foundations & Agile Mindset
During Sprint Retrospectives, two Developers frequently talk over the Product Owner and dismiss their input as “not technical,” causing the Product Owner to stop contributing. As Scrum Master, which action best reinforces the Scrum Value of Respect?
Best answer: B
What this tests: Scrum Foundations & Agile Mindset
Explanation: Respect in Scrum means team members value each other’s perspectives and collaborate as peers toward goals. When interruptions and dismissive behavior silence someone, the Scrum Master should coach the team to change how they work together. Facilitating working agreements makes expectations transparent and supports inspection and adaptation of team behaviors.
The Scrum Value of Respect is about recognizing each person’s contribution and treating one another as capable professionals. In this case, the behavior is preventing open participation and undermining collaboration, so the Scrum Master’s most effective response is to facilitate the team in inspecting the impact and adapting how they interact.
A practical coaching move is to help the Scrum Team create and own working agreements such as:
The key is enabling the team to self-manage toward respectful interactions rather than imposing control from outside the team.
Respect is reinforced by coaching the team to agree on and practice behaviors that ensure every voice is heard.
Topic: Scrum Foundations & Agile Mindset
It is Day 7 of a 10-day Sprint. The Sprint Goal is: “Users can reset their password via email.”
A stakeholder tells the Product Owner an urgent security incident requires “lock an account after 5 failed logins” to be delivered in this Sprint. The Product Owner tells the Developers to “just squeeze it in.” The Developers say they might fit it only by skipping automated tests, even though the Definition of Done requires automated tests and a security review. The Sprint ends in 3 days.
As Scrum Master, what is the BEST next action?
Best answer: A
What this tests: Scrum Foundations & Agile Mindset
Explanation: The team is being pushed to trade quality for speed, which violates Scrum values and undermines transparency. The Scrum Master should coach and facilitate an empirical conversation so the Product Owner and Developers can renegotiate the Sprint Backlog based on current progress while still meeting the Definition of Done. This keeps accountabilities intact and enables an informed decision about scope and timing.
In Scrum, new work can be discussed at any time, but adding it to the Sprint requires transparency about impact and a negotiation between the Product Owner and Developers. Skipping the Definition of Done reduces transparency and risks producing a non-releasable Increment, which undermines empiricism.
A good next step is to facilitate a brief session where:
The key takeaway is to protect quality and focus through empirical renegotiation, not through shortcuts or role overreach.
This preserves quality and focus by using transparency and renegotiation while keeping accountabilities clear (PO with stakeholders, Developers with the plan and DoD).
Topic: Events & Timeboxes
A Scrum Team’s Daily Scrum is consistently taking 25–35 minutes because discussions drift into solving design and dependency issues. The Scrum Master reviews the current Sprint Backlog excerpt:
Sprint Goal: Enable users to reset password via email
- PBI-21 Reset email template (Done)
- PBI-22 Token service endpoint (In Progress)
Impediment: Waiting on security team key rotation
- PBI-23 UI flow + validation (In Progress)
- PBI-24 Integration tests (To Do)
What is the best facilitation approach for the next Daily Scrum?
Best answer: B
What this tests: Events & Timeboxes
Explanation: The Daily Scrum is timeboxed to 15 minutes to minimize overhead and keep focus on inspecting progress toward the Sprint Goal and adapting the plan for the next day. The exhibit shows a clear impediment and multiple items in progress, which can be surfaced quickly without turning the event into a problem-solving session. Capturing follow-ups and continuing discussions with only the needed people respects the timebox and improves flow.
The Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog by creating a plan for the next 24 hours. The short timebox keeps coordination lightweight and encourages transparency without consuming excessive development time.
With the Sprint Backlog showing an explicit impediment and multiple items in progress, facilitation should keep the conversation centered on:
Any detailed design or dependency resolution should be captured (for example, as a “parking lot” topic) and handled immediately after the Daily Scrum by only the relevant people, rather than extending the event.
It preserves the Daily Scrum’s purpose—quick inspection and a plan for the next 24 hours toward the Sprint Goal—while moving problem-solving to a separate discussion.
Topic: Events & Timeboxes
A Scrum Team is halfway through a 2-week Sprint. Stakeholders are concerned because “nothing is done until the last days.” The Scrum Master looks at the Sprint Backlog board.
Exhibit: Sprint board (mid-Sprint)
Columns: To Do | Design | Build | Test | Done
PBIs (count): 0 | 3 | 3 | 3 | 0
Note from team: "Testing is planned for the final 2 days"
Which next action best addresses what the exhibit indicates while keeping incremental delivery within the Sprint?
Best answer: A
What this tests: Events & Timeboxes
Explanation: The board shows a phase-gated flow (design → build → test) with work accumulating and nothing reaching “Done,” which is a mini-waterfall inside the Sprint. The best response is to help the Developers re-plan their work to complete small slices to the Definition of Done continuously, producing at least one usable Increment during the Sprint.
The exhibit indicates a mini-waterfall pattern inside the Sprint: work is organized by phases and testing is deliberately deferred, resulting in zero PBIs reaching “Done” mid-Sprint. Scrum relies on empiricism, so the team should adapt the Sprint Backlog to maximize the chance of having “Done” work early and often.
A practical change is to help the Developers:
This preserves the Sprint timebox and restores incremental delivery rather than batching quality at the end.
It removes the mini-waterfall by finishing vertical slices to the Definition of Done throughout the Sprint instead of batching test at the end.
Topic: Events & Timeboxes
A Scrum Team is in Sprint Planning for a 2-week Sprint. The Developers start detailing tasks immediately after selecting work.
Exhibit: Draft Sprint Backlog (excerpt)
Product Goal: Reduce checkout abandonment
Sprint Goal: (not yet defined)
Selected Product Backlog Items:
- PBI-101 Guest checkout (8)
- PBI-108 Autofill shipping address (5)
- PBI-115 Improve payment error messages (3)
Plan (tasks): Started for PBI-101
Based on the exhibit, what is the best next action to complete Sprint Planning effectively?
Best answer: A
What this tests: Events & Timeboxes
Explanation: Sprint Planning addresses three topics: why the Sprint is valuable, what can be done, and how the work will be done. The exhibit shows work selection and tasking has started, but the Sprint Goal is missing. The team should first agree on a Sprint Goal to align decisions about scope and the plan.
In Sprint Planning, the Scrum Team collaborates on three topics in a coherent flow:
Here, the team has started on “what” (selected PBIs) and “how” (tasking started), but the “why” is explicitly missing. Establishing the Sprint Goal now creates shared understanding and guides trade-offs if scope or approach needs to change during planning or the Sprint.
Task breakdown is useful, but it should serve the Sprint Goal rather than happen without an agreed purpose.
Sprint Planning should first establish the Sprint’s purpose (why) so the selected work and plan support a shared objective.
Topic: Scrum Team & Accountabilities
A Scrum Team is struggling to deliver a high-quality Increment each Sprint. Work is frequently “finished by Dev” but then piles up in testing.
Exhibit: Sprint Backlog board snapshot
To Do: PB-12 Checkout UI
In Dev: PB-13 Promo codes
QA: PB-10 Login, PB-11 Cart totals, PB-14 Receipts
Done: -
Sprint Goal: "Customers can complete checkout"
Based on the exhibit, what is the best next action to address quality and clarify accountability?
Best answer: B
What this tests: Scrum Team & Accountabilities
Explanation: In Scrum, quality is not delegated to a separate role; the Developers are accountable for creating a usable Increment each Sprint. The exhibit shows work queuing in “QA,” suggesting testing is treated as a handoff instead of part of “Done.” The most effective response is to integrate quality work into the team’s flow by swarming and strengthening the Definition of Done.
The core accountability for quality in Scrum sits with the Developers: they are accountable for creating a usable Increment and for meeting the Definition of Done (DoD). The exhibit shows no items in “Done” and multiple items waiting in “QA,” which signals a mini-waterfall handoff where “done” means “dev complete” rather than meeting the DoD.
A practical Scrum response is to:
This builds quality in and restores an inspect-and-adapt flow toward the Sprint Goal.
Quality is owned by the Developers as a whole and is ensured by meeting a shared Definition of Done within the Sprint.
Topic: Artifacts & Commitments
A Scrum Team estimates Product Backlog items in refinement. The Product Owner uses the estimates to forecast a release window, but stakeholders start treating the forecast as a fixed delivery promise. When actual progress differs, the Developers are blamed and begin inflating estimates “to be safe.”
What is the most likely underlying cause in Scrum terms?
Best answer: A
What this tests: Artifacts & Commitments
Explanation: In Scrum, estimates are a tool to improve forecasting and help make trade-off decisions amid uncertainty. When stakeholders treat estimates and forecasts as guarantees, the system incentivizes padding, reduces transparency, and undermines empiricism. The symptoms described point to a misunderstanding of what estimation is (and is not).
Estimation in Scrum is used to create a forecast of what is likely, given current knowledge, and to support decisions such as ordering, scope negotiation, and release planning. Because complex work involves uncertainty, a forecast is expected to change as the Scrum Team learns through transparency, inspection, and adaptation.
In the scenario, stakeholders convert a forecast into a promise and then apply blame when outcomes differ, which drives the Developers to pad estimates. That behavior is a classic sign that estimates are being misused as a contract/guarantee rather than treated as probabilistic information that should be updated based on evidence (e.g., recent performance and what is learned each Sprint). The key takeaway is to restore shared understanding that forecasts evolve and should enable collaboration, not punishment.
Estimates support empirical forecasting and decision-making, not a fixed commitment that triggers blame when reality changes.
Topic: Scrum Master as Servant Leader
Mid-Sprint, the Developers are implementing a new API. Two Developers strongly disagree on an error-handling approach and ask the Scrum Master to “pick one so we can move on.” The decision does not change the Product Backlog scope, and the Product Owner is unavailable until tomorrow.
What is the best Scrum-aligned response from the Scrum Master?
Best answer: C
What this tests: Scrum Master as Servant Leader
Explanation: In Scrum, Developers are accountable for creating the Increment and self-managing how they work, including technical decisions. The Scrum Master’s role is to mentor by facilitating collaboration and enabling effective decision-making (for example, timeboxing, clarifying criteria, and encouraging inspection through a small experiment), not by dictating the solution.
The key factor is that the Developers are asking the Scrum Master to make a technical decision for them. In Scrum, the Scrum Master serves the team by coaching and facilitating, helping the Developers improve their practices and collaborate effectively while preserving their ownership of “how” the work is done.
A Scrum-aligned approach is to enable a quick, transparent decision process the Developers control, such as:
This keeps delivery moving and strengthens self-management rather than creating dependency on the Scrum Master or others.
The Scrum Master coaches the Developers’ self-management and decision-making without prescribing a technical solution.
Topic: Scrum Foundations & Agile Mindset
During the last two Sprints, a Product Owner and two Developers have repeatedly argued during Sprint Planning, with interruptions and dismissive comments. The Scrum Master facilitated a conversation about the Scrum value of respect and helped the Scrum Team create a simple working agreement for how to disagree and decide.
Which observation in the next Sprint best validates that the team is making real progress toward respectful, constructive collaboration?
Best answer: D
What this tests: Scrum Foundations & Agile Mindset
Explanation: Scrum relies on empiricism, so progress is validated through observable outcomes and behaviors that can be inspected. Seeing the team apply respectful disagreement and make shared decisions in Scrum events shows the working agreement is actually changing how they collaborate. This directly reflects the Scrum value of respect in day-to-day practice.
To validate improvement in a conflict scenario, look for inspectable evidence in how the Scrum Team collaborates while pursuing the Sprint Goal. Respect in Scrum is not proven by intent or extra activity; it is shown when people can surface disagreements, listen, and still make decisions together within Scrum events (Planning, Daily Scrum, Review, Retrospective). That observable pattern indicates the team has adapted its way of working and can continue to inspect and improve.
A strong indicator is therefore behavior you can see repeatedly: constructive dialogue, inclusive decision-making, and alignment around the Sprint Goal without personal attacks or shutdowns. Meetings, messages, or productivity metrics may be useful inputs, but they do not by themselves validate that respectful collaboration is happening.
Observable, repeated behavior changes in Scrum events provide the strongest evidence that respect and collaboration are improving.
Topic: Scrum Master as Servant Leader
Midway through a 2-week Sprint, a stakeholder asks the Developers to “quickly add a new reporting screen.” The Developers start the work immediately and do not tell the Product Owner or update the Sprint Backlog. The Sprint Goal is to “enable customers to complete checkout.”
What is the most likely near-term impact of this behavior?
Best answer: D
What this tests: Scrum Master as Servant Leader
Explanation: By accepting work directly from a stakeholder without involving the Product Owner or updating the Sprint Backlog, the team reduces transparency immediately. That makes inspection of progress unreliable and can quickly pull effort away from the Sprint Goal, increasing the risk of not meeting it (or cutting quality to compensate).
In Scrum, changes during the Sprint can happen, but they must be managed with transparency and with the Product Owner accountable for maximizing value and ordering the Product Backlog. When Developers take on new work “off the books,” the Sprint Backlog no longer reflects the real plan, so the Scrum Team can’t accurately inspect progress toward the Sprint Goal or adapt based on shared information.
Near-term consequences typically include:
The key issue is not that change is impossible, but that bypassing the Product Owner and not updating the Sprint Backlog undermines empiricism during the Sprint.
Untracked mid-Sprint changes obscure what’s being done and can immediately divert capacity from meeting the Sprint Goal.
Topic: Scrum Master as Servant Leader
A Scrum Team works in 2-week Sprints. Stakeholders keep asking for a firm release date, but the Product Owner’s forecast slips every Sprint even though the requested scope hasn’t changed.
In each Sprint Review, the Developers demo “done” features, yet several items later require extra testing, integration, and defect fixes in the next Sprint before they can be released.
What is the most likely underlying cause in Scrum terms?
Best answer: A
What this tests: Scrum Master as Servant Leader
Explanation: Predictability relies on transparent progress toward a releasable Increment. If items shown as “done” repeatedly need significant work afterward, the team is not consistently meeting a shared Definition of Done. That hidden remaining work makes forecasts unreliable and causes stakeholder date expectations to slip.
In Scrum, a “Done” Increment is the basis for inspecting progress and making credible forecasts. The clue that items demoed as “done” still need testing, integration, and defect fixing afterward points to a Definition of Done problem (unclear, not shared, or not adhered to).
When “done” doesn’t truly mean potentially releasable:
Strengthening and using a single Definition of Done for the Increment restores transparency and improves forecasting.
Calling work “done” while it still needs testing/integration indicates the Definition of Done isn’t being met, undermining forecasting and stakeholder expectations.
Topic: Scrum Master as Servant Leader
Midway through a Sprint, the Developers discover they cannot deploy to the shared test environment because an infrastructure certificate expired. Without that environment they cannot run required tests to meet the Definition of Done, and several Sprint Backlog items are now stuck.
As Scrum Master, what is the best next step?
Best answer: B
What this tests: Scrum Master as Servant Leader
Explanation: An impediment is an obstacle that prevents or slows the Developers from making progress toward the Sprint Goal. The expired certificate blocks the ability to meet the Definition of Done, so it should be made transparent and addressed immediately through impediment removal, while the Developers adapt their Sprint plan.
In Scrum, an impediment is anything that obstructs the Developers’ progress toward the Sprint Goal (for example, missing access, broken environments, external dependencies). It is different from normal work items or planned tasks, which are the activities the Developers choose to build a Done Increment.
Here, renewing the certificate is not product functionality; it is a blocker preventing required testing to satisfy the Definition of Done. The best next step is to make the impediment transparent and help remove it by collaborating with the right people (often outside the team), while the Developers adapt the Sprint Backlog based on the current reality.
Treating the blocker as “just another backlog item” delays recovery and reduces the team’s ability to meet the Sprint Goal.
An expired certificate blocking required testing is an impediment, so the next step is to remove it and adapt the plan rather than treating it as normal product work.
Topic: Scrum Team & Accountabilities
Mid-Sprint, two stakeholders approach the Product Owner with urgent requests.
The Developers say they can likely do only one of these without putting the Sprint Goal at risk, and both items are already refined in the Product Backlog. What should the Product Owner do to best optimize value and learning while respecting Scrum timeboxes?
Best answer: D
What this tests: Scrum Team & Accountabilities
Explanation: The Product Owner is accountable for maximizing value by ordering the Product Backlog and negotiating with stakeholders. In this situation, the best move is to make the value tradeoff explicit (including what is learned by delivering one request over the other) and then collaborate with the Developers to adjust scope only if the Sprint Goal remains achievable. This respects the Sprint timebox and preserves predictability around the Sprint Goal.
When stakeholder requests compete, the Product Owner makes the value decision by negotiating tradeoffs and ordering the Product Backlog. Urgency alone is not the decision rule; the Product Owner should clarify expected outcomes (value and learning), compare them, and communicate the chosen tradeoff.
To respect Scrum constraints mid-Sprint:
The key is transparent negotiation and ordering by value, not bypassing accountabilities or treating the Sprint as a buffer for every urgent request.
The Product Owner maximizes value by negotiating with stakeholders and ordering work, while preserving the Sprint Goal unless a mutually agreed Sprint Backlog adjustment is feasible.
Topic: Artifacts & Commitments
A Product Owner tells stakeholders that they should not expect the Product Backlog to ever be “finished.” As the product is used and the market changes, the team learns new things, and items are added, removed, clarified, and reordered over time.
Which Scrum concept best matches this situation?
Best answer: D
What this tests: Artifacts & Commitments
Explanation: The Product Backlog is designed to be emergent: it changes as more is learned about the product, users, and environment. Maintaining it over time means continuously updating and ordering it to maximize value and support the Product Goal. Because change and learning never stop, the Product Backlog is never “done.”
In Scrum, the Product Backlog is the single, transparent source of work undertaken by the Scrum Team for the product, and it is inherently emergent. That means its content and ordering are expected to evolve as outcomes are inspected, feedback is received, and new opportunities or constraints appear. Maintaining it over time includes ongoing refinement (adding detail, splitting, removing, and reordering items) so the most valuable and relevant work is clear for upcoming Sprints. The Product Goal provides longer-term direction, but it does not make the Product Backlog static; the backlog continues to change even when the goal remains the same.
Key takeaway: a “complete” Product Backlog would imply no new learning or change, which contradicts empiricism and product development reality.
It is an emergent, ordered list that evolves with learning and change, so it is never complete.
Topic: Scrum Team & Accountabilities
Midway through a Sprint, a key stakeholder tells the Product Owner, “We urgently need a new export format—this will be a game changer.” Developers are already working toward the Sprint Goal, and the Product Owner is considering reordering the Product Backlog and asking the Developers to switch.
What should the Product Owner verify or ask FIRST before deciding what to change?
Best answer: B
What this tests: Scrum Team & Accountabilities
Explanation: Maximizing product value starts with understanding what “value” means in the current context. Before changing priorities, the Product Owner should clarify the stakeholder’s actual need and the outcomes expected, so any Product Backlog ordering decision is based on evidence and impact rather than urgency language. Only then does it make sense to examine feasibility and Sprint-level trade-offs.
The Product Owner is accountable for maximizing value, which requires making ordering decisions based on the best available understanding of customer/stakeholder outcomes. In this situation, “urgent” and “game changer” are ambiguous; the first step is to clarify the underlying need, intended users, and measurable impact so the Product Owner can compare the request against the Product Goal and other Product Backlog items.
After the value hypothesis is clear, the Product Owner can inspect options such as:
Feasibility, Definition of Done considerations, and facilitation support are important, but they follow establishing what outcome is worth pursuing.
The Product Owner maximizes value by first clarifying the stakeholder need and expected outcomes before changing priorities.
Topic: Scrum Team & Accountabilities
A manager asks the Developers to “commit” to delivering an exact set of Product Backlog items by the end of the Sprint. The Developers explain that their estimates are used to create a forecast and a plan that will be updated as more is learned during the Sprint through inspection and adaptation.
Which Scrum concept best matches the Developers’ approach?
Best answer: B
What this tests: Scrum Team & Accountabilities
Explanation: In Scrum, estimates support forecasting, not fixed scope commitments. The Developers create and own a plan for how they expect to achieve the Sprint Goal, and they refine that plan as they learn more during the Sprint. That adaptive plan is captured in the Sprint Backlog.
Scrum uses empiricism, so plans are expected to change based on what is learned. Developers use estimates to help make a forecast of what they can accomplish and to build a plan for the Sprint; as new information emerges, they adapt that plan rather than treating it as a fixed contract for scope.
The Scrum artifact that represents this evolving forecast and plan is the Sprint Backlog: it includes the Sprint Goal, the selected Product Backlog items, and an actionable plan, and it is updated throughout the Sprint. A key takeaway is that the commitment is to the Sprint Goal and quality, while scope and the plan remain negotiable and adaptable within the Sprint.
The Sprint Backlog is the Developers’ plan for the Sprint and is updated throughout the Sprint as they learn.
Topic: Scrum Foundations & Agile Mindset
A Scrum Team’s Sprint Review is attended by stakeholders, the Product Owner, and the Scrum Master. Instead of reviewing a working product, the Developers show a slide deck of “90% done” items and explain that the code is in a separate branch and “will be integrated next Sprint.” Stakeholders can’t use the product and feedback is limited to timelines and scope. What is the most likely underlying cause in Scrum terms?
Best answer: C
What this tests: Scrum Foundations & Agile Mindset
Explanation: Effective inspection in the Sprint Review depends on transparent evidence of progress: a usable Increment. Here, the team is discussing partial work and deferred integration, which prevents stakeholders from inspecting the actual outcome and giving product feedback. The core issue is that “Done” work isn’t being produced to the Definition of Done, so a key inspection point is effectively being skipped.
In Scrum, inspection in the Sprint Review is centered on what was actually accomplished: the current Increment. That requires transparency created by having work that meets the Definition of Done and is integrated and usable. In this scenario, the team reports “90% done” items and shows slides because the code is not integrated and not ready for use, so stakeholders cannot inspect the product itself.
When a Sprint Review lacks a Done Increment:
The key takeaway is that strengthening adherence to the Definition of Done (and producing a Done Increment each Sprint) enables effective inspection at the Sprint Review.
Without a Done Increment, transparency is low and the Sprint Review can’t effectively inspect what was built.
Topic: Scrum Master as Servant Leader
You are the Scrum Master for a Scrum Team in a 2-week Sprint. During the Daily Scrum, the Developers say they are repeatedly blocked waiting for the Product Owner (PO).
Exhibit: Sprint Backlog board (excerpt)
Sprint Goal: Enable customers to reset passwords
In Progress: SB-12 Implement reset email
Blocked: SB-13 Copy updates (Waiting for PO approval)
Blocked: SB-15 Error message text (Waiting for PO decision)
Blocked: SB-18 Help page wording (Waiting for PO)
Done: SB-10 API endpoint
What is the best next action for you to take as Scrum Master?
Best answer: C
What this tests: Scrum Master as Servant Leader
Explanation: The exhibit shows multiple Sprint Backlog items blocked specifically by waiting for the PO, which threatens achieving the Sprint Goal. The Scrum Master’s best response is to make this impediment transparent and coach/help the PO create enough availability and decision cadence for the Scrum Team to proceed within the Sprint.
A Product Owner being unavailable is a Scrum anti-pattern because the PO is accountable for maximizing value and for effective Product Backlog management, which requires timely collaboration and decisions. The Sprint Backlog excerpt shows a pattern of blocked work explicitly waiting on the PO, so the Scrum Master should treat it as an impediment to the Scrum Team and address it with servant leadership.
Practical next steps include:
Letting others “fill in” as PO or pushing work out of the Sprint avoids the real impediment and weakens accountability.
The Scrum Master should coach and help the PO fulfill accountability by making availability transparent and enabling fast decisions needed to meet the Sprint Goal.
Topic: Scrum Master as Servant Leader
Midway through a Sprint, the Developers say they can finish all selected Product Backlog Items only if they skip several automated tests that are part of the team’s Definition of Done. The Product Owner is worried about missing the Sprint Goal.
Which action by the Scrum Master is NOT appropriate because it ignores the Definition of Done and risks quality?
Best answer: B
What this tests: Scrum Master as Servant Leader
Explanation: The Definition of Done is the shared quality bar for what can be considered part of the Increment. Allowing acceptance of work that does not meet the DoD creates a false sense of progress and weakens transparency. A Scrum Master should instead help the team adapt scope and plans while keeping the DoD intact.
In Scrum, “Done” has a specific meaning: work that meets the Definition of Done and can be included in the Increment. When the team is pressured to skip DoD activities (like required tests) to appear on track, quality and transparency are harmed because incomplete work may be treated as usable.
Appropriate Scrum Master actions protect the DoD by coaching and facilitation, for example:
The key is to adapt plans, not the meaning of “Done,” just to meet a date.
Treating work as “Done” without meeting the Definition of Done undermines transparency and builds in quality debt.
If you can pass multiple unseen attempts comfortably above the target range, take the real test when eligible instead of overtraining. The goal is to recognize good Scrum behavior in fresh situations, not memorize public wording.
This page gives one complete public CSM diagnostic. PM Mastery adds the larger CSM bank, focused topic drills, mixed timed mocks, progress tracking, and explanations that reinforce Scrum foundations and Scrum Master decision-making.
Do not retake immediately. Review every miss, reread the Scrum Guide passages behind the concept, and drill the weakest two domains before another timed attempt.
Use the CSM Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the CSM guide on PMExams.com for concept review, then return here for PM Mastery practice.