Try 10 focused PSM I questions on Applying Scrum in Practice, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | PSM I |
| Topic area | Applying Scrum in Practice |
| Blueprint weight | 10% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Applying Scrum in Practice for PSM I. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 10% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Applying Scrum in Practice
It is day 6 of a 10-day Sprint. The Sprint Goal is to deliver a self-service password reset flow. The Developers discover a production issue: a recent release causes some users to be locked out, and a stakeholder asks for a fix within 24 hours.
The Definition of Done requires code review and automated tests. The Developers believe they can complete the fix this Sprint only by dropping one lower-value Product Backlog item from the Sprint Backlog.
What is the best next action?
Best answer: C
What this tests: Applying Scrum in Practice
Explanation: In Scrum, emergent work is expected and should not be hidden. The Developers can update the Sprint Backlog as they learn more, and they should collaborate with the Product Owner when trade-offs are needed to meet urgent needs while preserving the Sprint Goal and quality. The Definition of Done should not be reduced just to fit more work into the timebox.
Unplanned operational work should be made transparent and handled through inspection and adaptation, not worked “off the books.” When urgent work appears during a Sprint, the Developers update the Sprint Backlog to reflect what they now plan to do, and they replan how to achieve the Sprint Goal.
Because dropping a lower-value item affects value delivery, the Developers should collaborate with the Product Owner to renegotiate scope while keeping the Definition of Done intact.
If the Sprint Goal truly becomes unattainable or obsolete, that is a separate decision; the key is transparency and informed adaptation within the Sprint timebox.
Unplanned urgent work should be handled transparently by updating the Sprint Backlog and renegotiating scope with the Product Owner without weakening the Definition of Done.
Topic: Applying Scrum in Practice
In Scrum, which term describes the shared, transparent understanding of the quality steps required for work to be considered complete, helping the Scrum Team respond to pressure to “skip testing” to meet a date?
Best answer: A
What this tests: Applying Scrum in Practice
Explanation: The Definition of Done is the Scrum Team’s explicit agreement on what “Done” means, including the quality activities needed to create a usable Increment. When someone pressures the team to skip quality steps, the DoD provides transparency and a basis to renegotiate scope or timing rather than hide unfinished work.
In Scrum, quality is built into the Increment through a transparent standard of completion: the Definition of Done. The DoD is used to assess whether work is truly complete and can be included in a usable Increment. If meeting a date requires “skipping testing,” that work is not Done and should not be represented as part of the Increment. Instead, the Scrum Team and stakeholders can inspect the situation and adapt by changing scope, ordering, or release expectations while keeping transparency about what is and is not Done. This protects empiricism by avoiding hidden work and accumulating technical debt through undisclosed shortcuts.
The Definition of Done makes required quality measures transparent and is used to determine whether work is part of a Done Increment.
Topic: Applying Scrum in Practice
A Scrum Team is building a product and stakeholders are pushing for a new feature this Sprint. During Sprint Planning, the Developers explain that recent shortcuts have increased defects and slowed delivery. They believe some refactoring and test automation must be done to meet the Definition of Done for the new feature and reduce ongoing support work.
What is the best next step?
Best answer: C
What this tests: Applying Scrum in Practice
Explanation: When quality work is necessary to deliver a Done Increment and reduce future cost, it should be made transparent and handled through normal Product Backlog ordering. The Product Owner and Developers collaborate during Sprint Planning to balance value, risk, and sustainability while crafting a Sprint Goal and selecting work they can complete. This keeps focus on value without hiding maintenance work or deferring it indefinitely.
In Scrum, balancing new features with quality and maintenance is done through transparency and Product Backlog ordering, not by separating “feature work” from “quality work.” If refactoring and test automation are needed to meet the Definition of Done (or to keep delivery sustainable), that work should be represented as Product Backlog Items (or clearly captured work) and ordered by the Product Owner with input from the Developers.
In Sprint Planning:
Deferring essential quality work or adding governance steps reduces transparency and usually increases future cost and slows value delivery.
Make the quality and maintenance work transparent and order it with feature work to maximize value while still meeting the Definition of Done.
Topic: Applying Scrum in Practice
Which statement best describes the purpose of the Sprint Retrospective in Scrum?
Best answer: B
What this tests: Applying Scrum in Practice
Explanation: The Sprint Retrospective is the Scrum event dedicated to continuous improvement. The Scrum Team inspects interactions, processes, tools, and their Definition of Done, then identifies and plans concrete improvements that strengthen quality and collaboration for future Sprints.
In Scrum, improvement actions that strengthen quality and collaboration are created in the Sprint Retrospective. Its purpose is for the Scrum Team to inspect how the last Sprint went regarding individuals, interactions, processes, tools, and their Definition of Done, and then adapt by selecting actionable improvements.
Typical outcomes are a small set of concrete changes the team will try in the next Sprint, such as improving the Definition of Done, addressing technical debt patterns, or adjusting collaboration practices. Product ordering and stakeholder feedback belong to other events and accountabilities, not the Retrospective.
Key takeaway: the Retrospective is where the team plans how to work better, not what to build next.
The Retrospective focuses on improving the Scrum Team’s ways of working, including quality and collaboration, and creating actionable improvements for the next Sprint.
Topic: Applying Scrum in Practice
Mid-Sprint, a stakeholder pressures the Scrum Team to “go faster” by skipping some automated tests and reducing the Definition of Done so a feature can be shown as complete. The Developers say they are “90% done” based on tasks finished.
Which is the best evidence to validate real progress and quality in this situation?
Best answer: C
What this tests: Applying Scrum in Practice
Explanation: In Scrum, the most reliable validation of progress and quality is a usable Increment that meets the Definition of Done. Under pressure to skip quality steps, task completion and optimistic forecasts can hide undone work and technical debt. A Done Increment makes quality transparent and supports inspection and adaptation.
When there is pressure to cut corners, Scrum relies on empiricism: only what is transparent and inspectable should be used to judge progress. The Definition of Done creates a shared understanding of what “complete” means, including necessary quality steps. Therefore, the strongest indicator that the team is truly progressing (and not merely accumulating undone work) is a usable Increment that meets the current Definition of Done.
Signals like task completion, time spent, or confidence in a forecast are indirect measures; they can increase even while critical quality work is deferred. If the team cannot produce a Done Increment, the appropriate response is to renegotiate scope and/or ordering with the Product Owner rather than weakening the Definition of Done.
Only a Done Increment provides transparent evidence of both progress and built-in quality.
Topic: Applying Scrum in Practice
During a Sprint Review, a stakeholder asks how the Scrum Team knows the Increment is truly ready to release. The Product Owner wants objective evidence, not opinions.
The Definition of Done includes: code merged to main branch, automated tests passing, security scan completed, and documentation updated.
Which evidence is most appropriate to show whether the Increment is Done?
Best answer: D
What this tests: Applying Scrum in Practice
Explanation: The most direct evidence that an Increment is Done is proof it meets the Definition of Done. The Definition of Done creates transparency about the quality and completeness required for the Increment to be usable. Other indicators (approval, charts, or release activities) do not, by themselves, demonstrate that the Definition of Done was satisfied.
In Scrum, an Increment is “Done” when it meets the Scrum Team’s Definition of Done, which is the explicit, shared commitment for the Increment. Because “Done” is a quality and completeness standard, the best evidence is objective verification against the Definition of Done items (for example, CI results showing automated tests passed, security scan results, and confirmation the work is integrated on the main branch with required documentation updated).
Measures like burn-down progress describe forecast or remaining work, and release/deployment is a business decision that can happen later. Acceptance or sign-off may help validate value and correctness, but it does not replace meeting the Definition of Done for determining whether the Increment is usable.
In Scrum, the Definition of Done is the shared standard for whether work is complete and usable, so evidence should directly demonstrate it is met.
Topic: Applying Scrum in Practice
During the Sprint, stakeholders keep asking the Developers for “percent of tasks completed.” The Scrum Team decides that in the Daily Scrum they will primarily discuss whether they are getting closer to the Sprint’s objective and adjust their plan when the objective is at risk, instead of reporting task completion.
Which Scrum concept best matches this practice?
Best answer: A
What this tests: Applying Scrum in Practice
Explanation: In Scrum, progress within a Sprint is primarily assessed against the Sprint Goal—the objective the Scrum Team is trying to achieve. Tasks are just a plan to meet that objective and can change as the team learns. Using the Sprint Goal as the main reference supports inspection and adaptation during the Sprint.
The Sprint Goal is the Sprint’s single objective and the commitment for the Sprint Backlog. Because the Sprint Backlog is a forecast and plan (not a fixed list of tasks), tracking “task completion” can give a false sense of progress. A better Scrum-aligned approach is to inspect each day whether the team is still on a path to achieve the Sprint Goal and adapt the Sprint Backlog as needed (for example, re-plan work, change tasking, collaborate differently, or negotiate scope with the Product Owner while keeping the goal intact when possible).
Key takeaway: within the Sprint, the most meaningful progress signal is movement toward the Sprint Goal, not the number of tasks done.
The Sprint Goal is the commitment for the Sprint Backlog and is the primary reference for Sprint progress over individual tasks.
Topic: Applying Scrum in Practice
Three Scrum Teams work on the same product and produce a single integrated Increment each Sprint. The teams notice that “finished” means different things across teams (for example, some include performance testing and documentation while others do not). They agree to use one shared standard for completeness so the Increment is consistently usable.
Which Scrum concept best matches what must remain consistent across the teams in this situation?
Best answer: C
What this tests: Applying Scrum in Practice
Explanation: When multiple Scrum Teams build the same product and integrate their work, they need a common understanding of what “Done” means. A shared Definition of Done makes the Increment’s quality transparent and enables the teams to combine their work into a single, usable Increment each Sprint. This consistency supports empiricism because stakeholders can inspect a reliable Increment at Sprint Review.
The situation describes a cross-team inconsistency in what “finished” means, which directly threatens transparency and the ability to produce a single integrated, usable Increment. In Scrum, the Definition of Done is the formal description of the state of the Increment when it meets the quality measures required for the product. When multiple Scrum Teams work on the same product, they must align on a shared Definition of Done (or ensure their individual definitions are compatible) so the integrated Increment meets a consistent quality standard. This is different from goals and backlogs: goals provide direction, while the Definition of Done sets the quality boundary for what can be considered part of the Increment. Key takeaway: shared product quality expectations must be consistent across teams building one product.
A shared Definition of Done creates a transparent, consistent quality bar for an integrated Increment.
Topic: Applying Scrum in Practice
A Scrum Team has increasing technical debt that is slowing delivery. The Developers propose a 2-day refactoring effort next Sprint, but the Product Owner says, “Do it, but don’t put it in the Product Backlog because stakeholders might question it.”
What is the best Scrum-aligned way to include this work transparently?
Best answer: D
What this tests: Applying Scrum in Practice
Explanation: Refactoring and quality improvements are legitimate Product Backlog work and must be transparent. Making them explicit Product Backlog items allows inspection and informed ordering alongside other work. Hiding the work undermines transparency and prevents stakeholders and the Product Owner from making trade-offs based on reality.
In Scrum, all work that is needed to improve the product—including quality improvements, reducing technical debt, and refactoring—should be made transparent. The Product Backlog is the single ordered list of what is needed to improve the product, so refactoring work belongs there as Product Backlog items (or clearly stated work within existing items) with enough clarity to enable inspection.
A Scrum-aligned approach is:
Keeping it out of the Product Backlog reduces transparency and makes empiricism harder because the true cost of delivering value is hidden.
Quality and refactoring work should be transparent as Product Backlog items so the Product Owner can order them against other value.
Topic: Applying Scrum in Practice
A company adds a second Scrum Team to work on the same product. Management decides each team will have its own Product Owner and its own Product Backlog “so they can move independently,” and the teams will combine their work “later.”
What is the most likely near-term impact of this decision?
Best answer: B
What this tests: Applying Scrum in Practice
Explanation: When multiple Scrum Teams work on one product, Scrum relies on a single Product Owner and a single Product Backlog to maximize transparency and enable effective inspection and adaptation. Splitting ownership and the Product Backlog makes it unclear what the product’s true priorities are and how the product is progressing toward the Product Goal. This obscures what stakeholders can learn at Sprint Review and makes adaptation harder.
With multiple Scrum Teams on the same product, key “one-product” elements stay unified: there should be one Product Owner accountable for value, one Product Backlog that is the single source of work, and one Product Goal. The teams may have separate Sprint Backlogs and coordinate their work, but they must be able to integrate into a coherent Done Increment.
Creating separate Product Owners and Product Backlogs for the same product immediately reduces transparency because there is no longer a single, clearly ordered view of what matters most and how current work contributes to the Product Goal. That weakens inspection at events like Sprint Review and makes adaptation of priorities and plans slower and more conflicted.
Coordination increases with multiple teams, but Scrum does not require changing Sprint length or dropping the Sprint Goal to address it.
With multiple Product Owners and Product Backlogs for one product, ordering and progress are no longer transparent and coherent for inspection and adaptation.
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, then return to PM Mastery for timed practice.