Try 10 focused CSM questions on Artifacts & Commitments, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | CSM |
| Topic area | Artifacts & Commitments |
| Blueprint weight | 18% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Artifacts & Commitments for CSM. 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: 18% 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: Artifacts & Commitments
A Product Owner has a Product Backlog with about 200 items. After a stakeholder meeting, the Product Owner asks the Developers to add detailed acceptance criteria and provide estimates for every Product Backlog item so the stakeholders can “lock the plan.”
As Scrum Master, what is the first thing you should clarify before advising on the appropriate level of detail?
Best answer: B
What this tests: Artifacts & Commitments
Explanation: Product Backlog items should be detailed progressively: the nearer an item is to being selected, the more it should be understood and decomposed. Clarifying which items are coming up soon identifies the time horizon that drives how much refinement is appropriate now. This prevents over-investing in detail for work that may change.
Product Backlog items are refined to an appropriate level of detail based on their proximity in time and likelihood of being selected. Items near the top of the Product Backlog (likely candidates for upcoming Sprints) should be small enough and clear enough to be selected in Sprint Planning and completed within a Sprint. Items further out can remain larger and less detailed because they are more likely to change as the Scrum Team learns.
By first clarifying which items are likely to be worked on next, the Scrum Master can guide the Product Owner toward just-in-time refinement: increase detail for near-term items and avoid premature specification for distant items that may be re-ordered or replaced. The key takeaway is that ordering/time horizon is the primary driver of “how detailed is detailed enough” right now.
Near-term items need more detail for selection and delivery, while longer-term items can stay coarse until they rise in ordering.
Topic: Artifacts & Commitments
During Sprint Planning for a 2-week Sprint, the Developers typically finish about 30 story points each Sprint (based on the last 5 Sprints). For the upcoming Sprint, two Developers are on vacation and one is in mandatory training, so the Developers estimate their capacity is about 70% of normal. The Product Owner asks to pull in about 30 points anyway to meet a date.
Which approach best optimizes predictability while still focusing on delivering value toward a Sprint Goal?
Best answer: C
What this tests: Artifacts & Commitments
Explanation: In Sprint Planning, the Sprint forecast should be based on what the Developers believe they can accomplish given current capacity and past performance. Historical throughput provides a starting point, and known capacity reductions should adjust that starting point. This supports a credible Sprint Backlog and a Sprint Goal the team can realistically pursue.
The Sprint forecast is the Developers’ best guess of what they can deliver in the Sprint while pursuing the Sprint Goal. A practical way to make that forecast is to start from past performance (recent throughput/velocity) and then adjust for known capacity changes such as vacations, training, or on-call duties. In this scenario, an average of 30 points with about 70% capacity suggests a forecast closer to 21 points, then selecting the most valuable Product Backlog Items that support a coherent Sprint Goal. This preserves transparency and predictability and enables meaningful inspection at the Daily Scrum and Sprint Review.
The key takeaway is that predictability comes from an honest forecast based on capacity and evidence, not from pressure, heroics, or lowering quality.
Using past throughput adjusted for current capacity creates the most realistic Sprint forecast for meeting a Sprint Goal.
Topic: Artifacts & Commitments
A Product Owner re-orders the Product Backlog so the top items are “most visible” UI changes requested by stakeholders. Developers point out a risky, uncertain integration item that several upcoming features depend on, and recommend doing it earlier to learn and reduce risk. The Product Owner keeps the integration item low because it has no immediate demo value.
What is the most likely near-term impact of this ordering decision?
Best answer: C
What this tests: Artifacts & Commitments
Explanation: Product Backlog ordering should consider value, risk, dependencies, and learning. Pushing a risky dependency down delays discovery and risk reduction, so the team is more likely to encounter blockers or rework during the next Sprint. That most directly threatens near-term progress toward the Sprint Goal.
Ordering the Product Backlog is a Product Owner decision, and effective ordering balances value with risk, dependencies, and opportunities to learn. When a foundational integration is uncertain and other work depends on it, placing it too low makes the next Sprint less predictable because critical information is deferred.
In the near term, this typically shows up as:
The immediate consequence is reduced ability to make steady progress toward the Sprint Goal, because the team discovers the dependency risk too late to adapt within the Sprint without significant disruption.
Deferring a risky dependency delays learning, increasing the chance the Sprint hits blockers or rework that undermines Sprint Goal progress.
Topic: Artifacts & Commitments
Midway through a Sprint, the Product Owner opens the team’s board and moves several Sprint Backlog items out, adds a new “urgent” item, and assigns tasks to specific Developers. A functional manager then messages the Developers with a task list and due dates for the rest of the Sprint.
As Scrum Master, what is the most Scrum-aligned response?
Best answer: B
What this tests: Artifacts & Commitments
Explanation: The Sprint Backlog is the Developers’ plan for meeting the Sprint Goal, and only they own and update it during the Sprint. The Product Owner can explain new needs and negotiate, but should not unilaterally re-plan the Sprint or assign tasks. The Scrum Master should restore self-management and enable collaboration around any change while keeping the Sprint Goal in focus.
A key Sprint Backlog anti-pattern is someone outside the Developers (a Product Owner or manager) unilaterally changing the Developers’ plan or assigning tasks. In Scrum, the Sprint Backlog is created by the Developers and is owned by them; it can be adapted during the Sprint as more is learned, but the adaptation is done by the Developers to manage progress toward the Sprint Goal.
A Scrum-aligned correction is to bring the “urgent” request into a conversation:
Freezing the Sprint Backlog or letting others assign work both undermine empiricism and the Developers’ ownership of the plan.
The Sprint Backlog is owned by the Developers, who adapt it as they learn, while the PO collaborates on scope/value without unilaterally changing or assigning the team’s work.
Topic: Artifacts & Commitments
During a Sprint, stakeholders say they are confused because they see two different “sources of truth” about progress.
Exhibit: Sprint Backlog (board excerpt)
Sprint Goal: Enable password reset via email
To Do: PB-41 API endpoint, PB-44 UI flow
In Progress: PB-42 Email template
Done (meets DoD): PB-40 Token generation
Note: PO also emails a daily "Status.xlsx" with these items
As Scrum Master, what is the best next action to increase transparency without creating duplicate systems?
Best answer: A
What this tests: Artifacts & Commitments
Explanation: A visible workflow board is meant to make the Sprint Backlog transparent so progress toward the Sprint Goal can be inspected. Maintaining a separate status spreadsheet creates a second system that will inevitably drift and reduce transparency. The best move is to align on one shared, visible Sprint Backlog and use it for status conversations.
In Scrum, the Sprint Backlog is the Developers’ plan for delivering the Sprint Goal, and it should be transparent to support inspection and adaptation. A workflow board is a common way to visualize the Sprint Backlog, but transparency drops when the team also maintains a separate “status” artifact that duplicates the same information.
A good next step is to:
The key is improving transparency by removing duplication, not by adding reconciliation work or shifting ownership away from Developers.
The Sprint Backlog is the Developers’ plan for the Sprint and should be made transparent; duplicating status in another system reduces transparency by creating mismatches.
Topic: Artifacts & Commitments
Which statement best defines the Sprint Goal and how it guides decisions during the Sprint?
Best answer: D
What this tests: Artifacts & Commitments
Explanation: The Sprint Goal is the single objective for the Sprint, created during Sprint Planning. It provides focus and a shared purpose so the Developers can make day-to-day decisions and adjust their plan while still working toward the same outcome. Changes in scope can be negotiated as long as the Sprint Goal remains achievable.
The Sprint Goal is the commitment for the Sprint Backlog and represents why the Sprint is valuable: a single objective the Scrum Team intends to achieve. During the Sprint, it guides decisions by giving the Developers a clear target for inspection and adaptation; they can re-plan, change tasking, and renegotiate Sprint Backlog scope with the Product Owner as new information emerges, provided the Sprint Goal is not put at risk. This is different from describing product direction (Product Goal), defining quality for the Increment (Definition of Done), or specifying expected behavior for an item (acceptance criteria). The key idea is that the Sprint Goal preserves focus while allowing flexibility in how the work is accomplished.
The Sprint Goal is the Sprint’s objective and is used to adapt the Sprint Backlog while keeping the purpose intact.
Topic: Artifacts & Commitments
A Scrum Team is finishing a Product Backlog item (PBI) near the end of the Sprint. The team’s Definition of Done includes:
The PBI meets everything except the security scan, which has not been run yet. Which statement is INCORRECT?
Best answer: A
What this tests: Artifacts & Commitments
Explanation: In Scrum, work is “Done” only when it meets the Scrum Team’s Definition of Done. Because the PBI has not satisfied the required security scan, it cannot be part of a Done Increment. Deferring unmet DoD work to a later Sprint while still calling the item Done reduces transparency and breaks the shared quality standard.
The Definition of Done is the shared quality standard that determines whether work is complete enough to be part of the Increment. If any DoD criterion is not met, the item is not Done and should not be included in the Increment.
In this scenario, the security scan is explicitly part of the DoD, and it has not been run. Therefore, the PBI cannot be treated as Done yet. Any remaining work to satisfy the DoD must be completed before the Sprint ends, or the item remains not Done and is handled transparently (for example, returned to the Product Backlog for future ordering).
Calling it Done while planning to complete a missing DoD step later is the key anti-pattern.
If the security scan in the Definition of Done is not met, the PBI cannot be considered Done.
Topic: Artifacts & Commitments
Midway through a Sprint, a stakeholder tells the Product Owner, “You estimated these Product Backlog Items at 20 points total, so you guaranteed they would all be done this Sprint. If not, I’ll escalate.” The team has uncovered unexpected complexity.
As Scrum Master, what is the best next step?
Best answer: A
What this tests: Artifacts & Commitments
Explanation: In Scrum, estimates are used to support forecasting, not to create a promise of delivery. When new complexity is discovered, the right response is to increase transparency and then inspect and adapt the forecast and plan. The Scrum Master helps ensure stakeholders understand uncertainty and supports collaborative trade-offs.
Estimation in Scrum is a technique to help the Scrum Team and stakeholders make decisions about likely future outcomes (forecasting). It is not a contract, guarantee, or promise that a specific scope will be delivered by a specific date.
When new information appears mid-Sprint (like unexpected complexity), the best next step is to improve transparency and enable inspection and adaptation. That typically means facilitating a conversation where the Product Owner and Developers explain what they’ve learned, and the Product Owner updates expectations and options (for example, adjusting scope, re-ordering the Product Backlog for future Sprints, or renegotiating what is most valuable to pursue next).
Trying to “force” the estimate to come true replaces empiricism with commitment to a guess.
Estimates support forecasting and should be inspected and adapted as new information emerges, rather than treated as a guarantee.
Topic: Artifacts & Commitments
A Scrum Team has consistently met its Sprint Goals, but stakeholders report too many defects after each release. Over the last two Sprints, the Developers have added automated unit tests and a CI pipeline that they believe can be used for most new code, though some legacy areas still lack test coverage.
The Scrum Master asks how the Definition of Done should evolve as the team’s capability improves, while keeping delivery predictable.
What is the best option?
Best answer: B
What this tests: Artifacts & Commitments
Explanation: The Definition of Done is a shared commitment to the Increment’s quality, and it should be raised as the Scrum Team’s capability increases. Making the tighter standard apply to all work improves transparency and reduces hidden rework. Predictability is maintained by adjusting the Sprint forecast and plan to meet the updated Definition of Done.
In Scrum, the Definition of Done creates transparency about what “complete” means for the Increment and is the basis for inspection at the Sprint Review. As the Scrum Team’s capabilities and engineering practices improve, the Definition of Done should evolve to reflect a higher, consistent quality bar.
A practical way to optimize quality and predictability is:
Using optional or delayed standards hides real “done-ness” and typically increases rework and unpredictability.
As capabilities improve, the Developers evolve the Definition of Done to increase transparency and quality, then adapt Sprint forecasts to remain predictable.
Topic: Artifacts & Commitments
A Product Owner is re-ordering the Product Backlog for a product with significant uncertainty. Several items have unclear requirements, some carry high technical risk, and one group of items depends on a planned API change. The Product Owner wants to maximize value while reducing the chance of late surprises.
Which Product Backlog ordering approach best matches Scrum principles?
Best answer: C
What this tests: Artifacts & Commitments
Explanation: In Scrum, the Product Owner orders the Product Backlog to best achieve the Product Goal by optimizing value. That ordering also accounts for uncertainty by bringing forward higher-risk work, dependencies, and items that enable learning, so the Scrum Team can inspect results sooner and adapt with better information.
The core concept is Product Backlog ordering by the Product Owner to optimize value while managing uncertainty. In the described situation, items with high technical risk, unclear requirements, and dependency constraints are signals to order work so the Scrum Team can learn earlier and reduce the likelihood of late surprises.
A practical ordering approach is:
This contrasts with ordering schemes based on fairness, effort alone, or keeping the Product Backlog fixed, which do not optimize outcomes toward the Product Goal.
Product Backlog ordering should optimize value and also consider risk, dependencies, and opportunities to learn early.
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, then return to PM Mastery for timed practice.