PSM I: Artifacts, Commitments, and Done

Topic snapshot

Sample questions

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.

Question 1

Topic: Artifacts, Commitments, and Done

During Sprint Planning, the Product Owner proposes the Sprint Goal: “Keep improving the product.” The Developers select several unrelated Product Backlog Items (a login enhancement, a performance spike, and a UI tweak). By the third day of the Sprint, the Daily Scrum is mostly status updates on tasks.

Which option is the best evidence that the Sprint Goal is missing or too vague, and what is the best correction?

• A. The team cannot state one outcome; rewrite a specific Sprint Goal with the PO.
• B. All selected items have detailed task breakdowns and hour estimates.
• C. The task board and burndown show steady day-to-day progress.
• D. Stakeholders agree in advance on the Sprint Review demo agenda.

Best answer: A

What this tests: Artifacts, Commitments, and Done

Explanation: A usable Sprint Goal is a single, coherent objective that creates focus and enables inspection of progress during the Sprint. When the Scrum Team cannot describe the outcome they are trying to achieve (and the Sprint Backlog looks like unrelated work), that is strong evidence the Sprint Goal is missing or vague. The correction is to collaborate with the Product Owner to craft a specific Sprint Goal and align the Sprint Backlog to it.

The Sprint Goal is the Sprint Backlog commitment and provides focus for the Sprint by describing a single valuable objective. It should be clear enough that the Scrum Team can inspect progress toward it (for example, in the Daily Scrum) and adapt the plan while keeping the goal intact.

In this scenario, “Keep improving the product” does not express a specific outcome, and the selected work is described as unrelated. The strongest evidence of a missing/vague Sprint Goal is that the team cannot articulate one coherent objective that ties the work together. The right correction is to work with the Product Owner to rewrite the Sprint Goal into a clear outcome and then adjust the Sprint Backlog so selected items meaningfully support that goal.

Task progress can be transparent, but it cannot replace a clear Sprint Goal for validating value-focused progress.

If the team cannot describe a single coherent objective, the Sprint Goal is too vague and should be made into a clear outcome.

Question 2

Topic: Artifacts, Commitments, and Done

A Scrum Team has had several defects escape into production over the last two Sprints. In the Sprint Retrospective they decide to adapt their Definition of Done by adding “automated regression tests passing” for every Product Backlog item.

They also agree to apply the updated Definition of Done immediately in the current Sprint. What is the most likely near-term impact?

• A. The Sprint Goal becomes invalid and the Sprint should be canceled
• B. Delivery speed will increase immediately because rework will be eliminated
• C. Fewer items may reach Done this Sprint, but transparency and quality increase
• D. There is no near-term impact because only the Product Owner can change quality standards

Best answer: C

What this tests: Artifacts, Commitments, and Done

Explanation: Quality issues are a signal that the current Definition of Done may not be sufficient to produce a usable Increment. Tightening the Definition of Done increases transparency about what is truly “Done” and tends to improve quality, but it commonly reduces the amount of work that can be completed in the short term. Applying it immediately can put Sprint Goal progress at risk and requires replanning within the Sprint as needed.

The Definition of Done is the Scrum Team’s shared quality measure for an Increment; when real quality problems are discovered (such as escaped defects), it should be inspected and adapted to make future work more likely to be usable. If the Scrum Team tightens the Definition of Done and applies it immediately, the near-term effect is usually that some work previously thought “almost done” no longer qualifies as Done, reducing the amount of completed work visible at the Sprint Review.

Developers can then adapt their plan by updating the Sprint Backlog and negotiating scope as needed while keeping the Sprint Goal in focus. The key takeaway is that improving the Definition of Done increases transparency and quality, often at the cost of short-term throughput.

Raising the Definition of Done makes “Done” more stringent right away, which can reduce near-term throughput while improving transparency and product quality.

Question 3

Topic: Artifacts, Commitments, and Done

A Scrum Team has a Sprint Review tomorrow. The Product Owner says stakeholders are frustrated because recent Sprint Reviews have focused on “90% done” work, and decisions about what to do next keep changing once the unfinished work is completed later.

Today the Developers realize that, as planned, none of the Product Backlog Items are likely to meet the Definition of Done by the end of the Sprint.

What is the best next step?

• A. Hold the Sprint Review as planned and demonstrate the unfinished work so stakeholders can give early feedback.
• B. Extend the Sprint by a few days so the team can complete everything before holding the Sprint Review.
• C. Re-plan the Sprint Backlog to finish a small set of items to the Definition of Done and present that Done Increment at the Sprint Review.
• D. Add a separate “hardening/UAT Sprint” after each Sprint so work can become Done before stakeholders see it.

Best answer: C

What this tests: Artifacts, Commitments, and Done

Explanation: The Sprint Review is for inspecting a usable Increment and adapting the Product Backlog based on what was actually achieved. When work is not Done, inspection becomes unreliable because stakeholders are reacting to assumptions and partial results. Re-planning to complete at least a small Done Increment maximizes transparency and supports meaningful decisions.

A Done Increment each Sprint is essential because the Sprint Review is an inspection of the current state of the product, not a status meeting about progress. Only work that meets the Definition of Done is integrated, usable, and transparent enough for stakeholders to evaluate and for the Scrum Team to adapt the Product Backlog with confidence. When “almost done” work is shown, feedback and decisions are based on incomplete functionality, unknown remaining work, and unverified quality, which often forces rework and changing plans later.

The best next step is to adapt within the Sprint by re-planning the Sprint Backlog so the Developers focus on getting at least one valuable slice to Done, creating a real Increment to inspect at the Sprint Review. Extending the Sprint or adding hardening phases reduces empiricism by delaying inspection and adaptation.

A Done Increment is what enables reliable inspection and adaptation at the Sprint Review; re-planning to get at least something to Done restores that feedback loop.

Question 4

Topic: Artifacts, Commitments, and Done

Midway through a 2-week Sprint, a security stakeholder reports a critical vulnerability in the latest Increment. The Developers realize their current Definition of Done does not include an automated security scan, and the Product Owner asks to keep the completed Product Backlog Items marked as Done so a Sprint Review demo can proceed. The Sprint ends in 3 days and the Sprint Goal is still valuable.

What is the BEST next action?

• A. Have the Developers update the Definition of Done now to include the security scan, and then re-plan with the Product Owner based on what can still meet the Sprint Goal.
• B. Keep the Definition of Done unchanged, but add a separate security checklist that items can follow after the Sprint Review.
• C. Ask the Product Owner to update the Definition of Done to reflect the stakeholder’s security requirement.
• D. Wait until the Sprint Retrospective to update the Definition of Done so the Sprint Review is not disrupted.

Best answer: A

What this tests: Artifacts, Commitments, and Done

Explanation: The Definition of Done exists to create transparency about what “Done” means and the quality required for the Increment. When a real quality gap is discovered, it should be addressed by adapting the Definition of Done rather than continuing to label work as Done under an inadequate standard. After updating it, the Scrum Team can adjust the Sprint Backlog to protect the Sprint Goal as much as possible.

A quality issue found through inspection is a signal that the current Definition of Done may not be sufficient to produce a usable Increment with the needed level of quality and transparency. The Developers are accountable for the Definition of Done (or for conforming to an organizational one), and they can evolve it as they learn.

Best next action is to:

• Adapt the Definition of Done as soon as the gap is understood (so “Done” remains meaningful).
• Make the impact transparent by re-planning the Sprint Backlog with the Product Owner.
• Treat work that does not meet the updated Definition of Done as not Done.

Waiting to change it, shifting ownership to the Product Owner, or creating side checklists undermines transparency and can allow low-quality Increments to be presented as complete.

When inspection reveals the current Definition of Done is insufficient for required quality, the Developers adapt it immediately and make scope/plan adjustments transparent.

Question 5

Topic: Artifacts, Commitments, and Done

Midway through a Sprint, the Developers discover a critical production defect caused by the product. They want to add work to fix it immediately and remove a lower-value Product Backlog item from the Sprint.

The Product Owner refuses, saying, “The Sprint Backlog is our contract for the Sprint; we can’t change it once Sprint Planning is over.”

As the Scrum Master, which TWO responses best correct this behavior? (Select TWO)

• A. Direct the Developers to work overtime to meet the original Sprint Backlog commitment
• B. Extend the Sprint timebox so the team can complete both the original work and the defect fix
• C. Coach that the Sprint Backlog is an emergent plan owned by the Developers and can be updated during the Sprint
• D. Defer the defect to the next Sprint because the Sprint Backlog cannot change after Sprint Planning
• E. Require a formal change request and Product Owner sign-off before any Sprint Backlog change
• F. Facilitate a discussion between Product Owner and Developers to inspect the impact and adjust the Sprint Backlog while keeping the Sprint Goal in focus

Correct answers: C, F

What this tests: Artifacts, Commitments, and Done

Explanation: In Scrum, the Sprint Backlog is a forecast and a plan created by the Developers, and it is expected to evolve during the Sprint. When new information arises (like a critical defect), the Scrum Team should collaborate to re-plan and update the Sprint Backlog while keeping the Sprint Goal as the central guide.

Treating the Sprint Backlog as a contract is an anti-pattern because it reduces adaptation and undermines empiricism. The Sprint Backlog is composed of the Sprint Goal, selected Product Backlog items, and a plan for delivering them; it is owned by the Developers and is updated throughout the Sprint as the team learns.

When a critical defect is discovered mid-Sprint, the right response is to make the work transparent and collaborate:

• Inspect how the defect affects the Sprint Goal and expected value.
• Adapt the plan by adding the defect work and removing or changing other work as needed.
• Use the Sprint Goal as the key constraint, not a promise to deliver every originally selected item.

Freezing scope, adding approvals, or extending the timebox blocks adaptation and misuses Scrum’s events and accountabilities.

The Sprint Backlog is not a fixed scope contract; it is a plan that Developers adapt as more is learned.

Changes to planned work are handled by collaboration and re-planning around the Sprint Goal, not by freezing scope.

Question 6

Topic: Artifacts, Commitments, and Done

Mid-Sprint, the Developers report they are “about 80% done” based on tasks completed on the Sprint Backlog. The Sprint Goal is posted and unchanged: “Customers can reset their password without contacting support.”

However, the work is still spread across branches, testing is planned for the last day, and there is no integrated, usable functionality that could be shown in its current state.

Which underlying Scrum cause best explains why the team lacks reliable evidence of progress toward the Sprint Goal?

• A. A weak or unused Definition of Done, resulting in no usable Done Increment
• B. Accountability confusion, because the Scrum Master should be tracking progress for the Developers
• C. A lack of transparency because the Product Owner is not sharing Product Backlog information
• D. An unclear Sprint Goal, so the team cannot determine what progress means

Best answer: A

What this tests: Artifacts, Commitments, and Done

Explanation: Progress toward the Sprint Goal is best evidenced by a usable Increment that meets the Definition of Done, not by task completion percentages. The clues show work is not integrated or potentially releasable, so the team cannot inspect real progress. This most strongly points to an ineffective or unused Definition of Done leading to no Done Increment during the Sprint.

In Scrum, the most meaningful evidence of progress toward the Sprint Goal is the state of the Increment: integrated, usable, and meeting the Definition of Done. Task completion and “percent done” are activity metrics; they can look positive even when there is no working product value to inspect.

Here, the Sprint Goal is clear and visible, but the team has deferred integration and testing, leaving nothing usable to show mid-Sprint. That indicates they are not producing a Done Increment throughout the Sprint, which commonly stems from a weak Definition of Done or not using it to guide daily work. The key takeaway is to use the Done Increment as the transparent basis for inspection and adaptation toward the Sprint Goal.

Without meeting a Definition of Done during the Sprint, task completion does not provide evidence of progress toward the Sprint Goal.

Question 7

Topic: Artifacts, Commitments, and Done

A Scrum Team notices that Product Backlog ordering has become a monthly negotiation among several stakeholder groups. The Scrum Master is asked what to do next.

Exhibit: Product Backlog excerpt

Product Goal: Reduce customer support calls by 20%

1. New onboarding flow              Order: 1 (Marketing vote)
2. Improve page load time           Order: 2 (Support vote)
3. Legal reporting export           Order: 3 (Compliance vote)
Note: "Final order set in monthly Steering Committee meeting"

What is the best Scrum-aligned next action supported by the exhibit?

• A. Create separate Product Backlogs per stakeholder group so each can order independently
• B. Keep the Steering Committee, but add stricter voting rules and a timebox
• C. Ask the Developers to re-order the items based on technical dependencies
• D. Coach the Product Owner to own ordering, using stakeholder input but not committee decisions

Best answer: D

What this tests: Artifacts, Commitments, and Done

Explanation: The exhibit shows ordering is being decided by a stakeholder committee (“final order set” by votes). In Scrum, ordering the Product Backlog is the Product Owner’s accountability, while stakeholders provide input and collaborate. A Scrum-aligned correction is to restore clear accountability and make the PO’s ordering transparent against the Product Goal.

The core issue in the exhibit is a loss of accountability: a “Steering Committee meeting” and stakeholder “votes” are effectively making ordering decisions. In Scrum, the Product Owner is accountable for maximizing value, which includes ordering the Product Backlog. Stakeholders are important collaborators, but they do not replace the Product Owner’s decision-making.

A Scrum-aligned correction is to help the Product Owner:

• Reclaim and communicate that they set the final order
• Use stakeholder input (needs, risks, opportunities) as information, not as a vote
• Make the ordering rationale transparent in relation to the Product Goal

This preserves empiricism by enabling clearer inspection and adaptation of ordering based on outcomes rather than committee politics.

The Product Owner is accountable for ordering the Product Backlog and can collaborate with stakeholders for input without handing over the decision.

Question 8

Topic: Artifacts, Commitments, and Done

Midway through a 2-week Sprint, the Developers finish several Product Backlog Items and want to show them to stakeholders immediately. The work currently passes all automated tests, but it has not been integrated with the rest of the product and the team’s Definition of Done requires integration and a security scan. The Sprint Goal is to validate a new checkout flow with real users at the Sprint Review.

What is the BEST next action?

• A. Ask the Product Owner to waive the Definition of Done for this Sprint
• B. Demo the completed parts now as long as stakeholders agree it is not Done
• C. Move the items back to the Product Backlog and start new work that can be shown sooner
• D. Integrate and complete the security scan so the work meets the Definition of Done

Best answer: D

What this tests: Artifacts, Commitments, and Done

Explanation: An Increment is a concrete step toward the Product Goal that is usable and meets the Definition of Done. Because integration and the security scan are required by the team’s Definition of Done, the current state is not a usable Increment yet. The best action is to finish the DoD work so stakeholders can inspect a transparent, potentially releasable Increment at the Sprint Review.

The Increment is the sum of all Product Backlog Items completed during a Sprint plus the value of previous Increments. For completed work to be part of the Increment, it must be usable and meet the Scrum Team’s Definition of Done; otherwise transparency is reduced because stakeholders may interpret “done” functionality that is not actually integrated and ready.

In this scenario, the Developers have work that looks “finished” but still lacks required integration and a security scan. The best next action is to complete those DoD activities so the result is a potentially releasable Increment that can be inspected against the Sprint Goal at the Sprint Review. If the Sprint Goal is at risk, the team can adapt the Sprint Backlog and collaborate with the Product Owner on scope, but not by bypassing the Definition of Done.

Only work that meets the Definition of Done can be part of the Increment, so finishing DoD work preserves usability and transparency.

Question 9

Topic: Artifacts, Commitments, and Done

A Scrum Team is building a mobile banking app. At the Sprint Review, stakeholders inspect the latest Increment and report that a recently announced regulation will require different capabilities sooner than expected. During the next week, the Product Owner inspects production telemetry from earlier Increments and sees that a released feature is rarely used and users abandon the flow.

Which TWO actions reflect when the Product Backlog should be adapted based on these inspection results? (Select TWO)

• A. Freeze the Product Backlog during the Sprint to avoid change
• B. Let Developers re-order the Product Backlog in the Daily Scrum
• C. Wait to adapt the Product Backlog until after the Sprint Retrospective
• D. Re-order Product Backlog items after Sprint Review feedback
• E. Add or adjust Product Backlog items based on telemetry learning
• F. Update the Product Backlog only during Sprint Planning

Correct answers: D, E

What this tests: Artifacts, Commitments, and Done

Explanation: The Product Backlog is an emergent artifact and should be adapted whenever inspection reveals new information about value, risk, or what is needed. Sprint Review feedback is a key inspection point for adjusting ordering. Inspection of actual product outcomes (such as telemetry) can also drive immediate Product Backlog updates by the Product Owner.

In Scrum, inspection results should lead to timely adaptation to maximize value. The Product Backlog is continuously refined and can be updated at any time; it is not limited to a specific event or “change window.” When stakeholders inspect the Increment at the Sprint Review and new constraints or opportunities emerge, the Product Owner adapts the Product Backlog (often by re-ordering items or adding new ones). Likewise, inspecting real usage and outcomes between events can reveal that assumptions were wrong or needs changed, and the Product Backlog should be updated promptly.

Key takeaway: adapt the Product Backlog whenever inspection provides new, actionable learning; don’t wait for a single ceremony or delegate Product Backlog ordering to others.

Sprint Review inspection can change what is most valuable, so the Product Backlog ordering should be adapted.

Ongoing inspection of outcomes can reveal new work or changed priorities, prompting Product Backlog adaptation.

Question 10

Topic: Artifacts, Commitments, and Done

Halfway through a Sprint, the Developers discover an additional integration task with an external email service that was not identified in Sprint Planning. Without this work, they cannot deliver a Done Increment toward the Sprint Goal, and they now believe some originally planned Sprint Backlog items may not fit.

Which TWO actions best handle this new work while preserving focus on the Sprint Goal? (Select TWO)

• A. Keep the Sprint Backlog unchanged until the next Sprint Planning
• B. Update the Sprint Backlog and re-plan the remaining work
• C. Escalate for management approval before changing any Sprint work
• D. Work with the Product Owner to renegotiate Sprint Backlog scope
• E. Cancel the Sprint and immediately start a new Sprint with the new work
• F. Have the Product Owner add the new task directly to the Sprint Backlog

Correct answers: B, D

What this tests: Artifacts, Commitments, and Done

Explanation: New work can be discovered during the Sprint, and the Scrum Team should respond while keeping the Sprint Goal as the guiding purpose. The Developers adapt their plan by updating the Sprint Backlog, and if the new work changes what can be delivered, the Product Owner and Developers renegotiate scope to maintain focus on the Sprint Goal.

The Sprint Backlog is the Developers’ plan for achieving the Sprint Goal, and it is expected to change as the Developers learn more during the Sprint. When new necessary work is discovered, the Developers add it and re-plan their work so they can still produce a Done Increment.

If the new work changes the delivery forecast, the Product Owner and Developers collaborate to renegotiate Sprint Backlog scope (for example, dropping or swapping lower-value work) while keeping the Sprint Goal as the key focus. The Product Owner does not unilaterally direct changes to the Sprint Backlog, and extra approval steps that delay adaptation reduce empiricism.

The Sprint Backlog is owned by the Developers and is updated as more is learned during the Sprint.

If new work affects the forecast, the Product Owner and Developers collaborate to adjust scope while keeping the Sprint Goal intact.

Continue with full practice

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.

Related focused pages

• Free PSM I Full-Length Practice Exam
• PSM I: Scrum Theory, Values, and Empiricism
• PSM I: Scrum Team and Accountabilities
• PSM I: Scrum Events and Timeboxes
• PSM I: Applying Scrum in Practice

Free review resource

Read the PSM I guide on PMExams.com, then return to PM Mastery for timed practice.