Scrum Master Exam: Mastering Scrum Artifacts and Commitments (2026)

If there's one area that trips up Scrum Master candidates more than almost any other, it's the relationship between Scrum's three artifacts and their corresponding commitments. Not because the concepts are complicated in isolation — most candidates can name the artifacts without blinking — but because exam questions love to test whether you truly understand why those commitments exist, who owns them, and what happens when they're ignored or misapplied in a real team environment.

The 2020 Scrum Guide introduced a meaningful structural shift by formally pairing each artifact with a specific commitment. This wasn't just a cosmetic update. It was Scrum's way of making the purpose of each artifact explicit — turning them from passive documentation into living tools that support transparency, inspection, and adaptation. If you're preparing for the PSM I (Professional Scrum Master) through Scrum.org or the CSM (Certified Scrum Master) through Scrum Alliance, understanding this three-artifact, three-commitment framework at a deep level will directly improve your score on situational questions.

This article is going to walk through each artifact and commitment pair thoroughly, explore how they support empiricism, and flag the specific misconceptions that cause candidates to miss questions they should be getting right. Let's get into it.

---

Understanding the Role of Artifacts in Scrum

Scrum artifacts represent work or value. That's the straightforward definition. But what makes them genuinely useful isn't that they store information — it's that they create a shared, transparent picture of reality that allows a Scrum Team to inspect what's happening and adapt accordingly.

Think about what Scrum is actually built on: empirical process control. The three pillars — transparency, inspection, and adaptation — only function when information is visible and honest. Artifacts are the primary mechanism through which that transparency happens. Without them, the team is essentially navigating without instruments.

The 2020 Scrum Guide identifies three artifacts:

• Product Backlog — represents the entire body of work to be done on the product
• Sprint Backlog — represents the plan for the current Sprint
• Increment — represents the sum of completed, usable work

Each artifact now has an associated commitment that gives it a north star — a clear purpose that prevents the artifact from becoming just a list of items or a bureaucratic checkbox.

Why Commitments Were Added

Before the 2020 update, teams often struggled to articulate what their artifacts were actually for beyond their mechanical function. Product Backlogs became sprawling wish lists. Sprint Backlogs turned into task trackers divorced from any meaningful goal. Increments got shipped without any consistent quality standard.

The commitments address this directly. They're not add-ons — they're the answer to the question "what does this artifact serve?" A Scrum Master who understands this framing will approach artifact-related questions from a purpose-driven perspective rather than a procedural one, which is exactly the mindset the PSM I exam rewards.

---

The Product Backlog and the Product Goal Commitment

The Product Backlog is owned and managed by the Product Owner. This is important and comes up frequently in exam questions. The Scrum Master doesn't own the Product Backlog, and neither does the Development Team — though both interact with it meaningfully.

The Product Backlog is an ordered, emergent list of everything needed to improve the product. It's never "done" in the traditional sense; it evolves as the product and market understanding evolve. Items near the top are typically more refined, smaller, and ready for Sprint Planning. Items further down may be vague, large, or exploratory.

The Product Goal: The Commitment That Gives It Direction

The Product Goal is the commitment for the Product Backlog. It describes the future state of the product and serves as the long-term objective the Scrum Team works toward. Every item in the Product Backlog should, in some way, serve or relate to achieving the Product Goal.

Here's where this gets practically meaningful: without a Product Goal, a Product Backlog becomes a random collection of feature requests and technical tasks. The Product Goal acts as the filter — it helps the Product Owner decide what belongs in the backlog, what gets prioritized, and what can be removed. It's the "why" behind the "what."

Exam mindset: When you see a question where the team is spinning their wheels, adding random features, or unable to prioritize, think Product Goal. The Scrum Master's role in this context is to coach the Product Owner on articulating and maintaining a clear Product Goal — not to write it themselves.

A few things worth knowing for the exam:

• The Product Goal exists in the Product Backlog
• The Scrum Team pursues one Product Goal at a time
• A new Product Goal can only be set after the current one is either achieved or abandoned
• Refinement is the ongoing process of adding detail, order, and size to Product Backlog items — it's not a formal Scrum event but a continuous activity

---

The Sprint Backlog and the Sprint Goal Commitment

The Sprint Backlog is often misunderstood as just a task list for the Sprint. It's actually a real-time, transparent picture of the work the Developers plan to accomplish, owned and managed by the Developers themselves — not the Scrum Master, and not the Product Owner.

The Sprint Backlog has three components:

1. The Sprint Goal (the why)
2. The selected Product Backlog items (the what)
3. A plan for delivering the Increment (the how)

This three-part structure is itself exam-worthy. Many candidates can name the Sprint Backlog but can't articulate what it contains. Knowing all three components matters.

The Sprint Goal: Flexibility Within Focus

The Sprint Goal is the commitment for the Sprint Backlog. It's created during Sprint Planning and gives the Developers a single objective for the Sprint. The Sprint Goal is important because it creates coherence — it's the reason all those selected backlog items belong together in the same Sprint.

The Sprint Goal also provides flexibility. If the Developers discover during the Sprint that their approach isn't working, they can negotiate the scope of the Sprint Backlog with the Product Owner without abandoning the Sprint Goal. This is a subtle but critical point that shows up in scenario questions.

Real-world example: Imagine a team is building an e-commerce checkout flow. Their Sprint Goal is "Enable customers to complete a purchase using a credit card." Halfway through the Sprint, they realize the payment gateway integration is more complex than expected. They can descope some of the styling work or error-handling edge cases (Sprint Backlog items) while still working toward the Sprint Goal. What they can't do is pivot to something completely unrelated.

Exam mindset: If a question presents a scenario where someone outside the Developers is changing the Sprint Backlog mid-Sprint, that's a problem. The Scrum Master's responsibility here is to protect the Sprint — a core servant leadership function. The Developers own the Sprint Backlog and the plan for how to achieve the Sprint Goal. Stakeholders and Product Owners can negotiate scope with the Developers, but they can't unilaterally add or change tasks.

---

The Increment and the Definition of Done (DoD)

The Increment is the most tangible artifact. It's the sum of all completed Product Backlog items that meet the Definition of Done — and this is where candidates often lose points, because they conflate "done" with "deployed" or "approved by the stakeholder."

Multiple Increments can be created within a single Sprint. Every time a Product Backlog item meets the Definition of Done, you have an Increment. The Increment must be usable and potentially releasable, even if the Product Owner decides not to release it.

The Definition of Done: Quality as a Commitment

The Definition of Done (DoD) is the commitment for the Increment. It's a formal description of the quality standard that work must meet before it can be considered part of an Increment. If a Product Backlog item doesn't meet the DoD, it cannot be included in the Increment — full stop.

Who creates the DoD? This is where the exam likes to test precision. If the organization has an existing Definition of Done, the Scrum Team must comply with it as a minimum. If no organizational standard exists, the Scrum Team creates it. The Developers are primarily responsible for adhering to it, but the entire Scrum Team owns the commitment.

The DoD is also a transparency mechanism. It ensures that when someone says work is "done," everyone on the team — and ideally everyone in the organization — has the same understanding of what that means.

Practical tip: A strong DoD typically includes things like:

• Code reviewed and merged
• Unit tests passing
• Acceptance criteria met
• No known critical bugs
• Documentation updated

What it should not include is approval from an external stakeholder or sign-off from the Scrum Master. Done means done — it's an internal quality standard, not an external approval gate.

---

How Artifacts Ensure Transparency and Empiricism

Here's the through line that makes this entire framework coherent: artifacts exist to serve empiricism. Scrum is not a prescriptive methodology that tells you exactly what to build and how. Instead, it creates conditions where teams can learn, adapt, and improve based on evidence.

For empiricism to work, information needs to be transparent — visible to everyone who needs it, honest, and up to date. The three artifacts, supported by their commitments, are the primary vehicles for that transparency.

• The Product Backlog makes visible what the team believes needs to be done to achieve the Product Goal
• The Sprint Backlog makes visible what the team has committed to doing this Sprint and how they plan to do it
• The Increment makes visible what has actually been accomplished and whether it meets the quality standard

When artifacts are hidden, poorly maintained, or disconnected from their commitments, empiricism breaks down. Teams start making decisions based on assumptions instead of facts. This is why the Scrum Master — as a servant leader — invests significant energy in keeping artifacts healthy, coaching the team on their purpose, and surfacing problems before they become bigger issues.

---

Common Exam Pitfalls: Artifact Ownership and Updates

Let's be direct about the mistakes that candidates make most often.

Pitfall 1: Confusing who owns each artifact

Artifact	Owner
Product Backlog	Product Owner
Sprint Backlog	Developers
Increment	Scrum Team (created by Developers)

The Scrum Master doesn't own any artifact. The Scrum Master serves the process and the people — not the artifacts.

Pitfall 2: Thinking the Sprint Backlog is locked after Sprint Planning

It's not. The Sprint Backlog is updated throughout the Sprint as the Developers learn more. What can't change without careful negotiation is the Sprint Goal itself — that stays stable unless something truly extraordinary makes the Sprint obsolete.

Pitfall 3: Assuming the Definition of Done and Acceptance Criteria are the same thing

They're not. Acceptance Criteria are specific to a Product Backlog item — they describe what "done" means for that item. The Definition of Done is the overarching quality standard that applies to all items. An item can meet its Acceptance Criteria and still fail the DoD if it doesn't meet the team's quality standards.

Pitfall 4: Thinking only one Increment is created per Sprint

As mentioned earlier, multiple Increments can be created within a Sprint. Each completed Product Backlog item that meets the DoD is an Increment.

---

Practice Scenarios: Applying Artifacts in Real-World Situations

Reading about artifacts is useful. Applying them to scenarios is where the real exam preparation happens.

Scenario 1: During Sprint Review, the Product Owner tells the team that three of the five completed items are "done." The Developers disagree — they say all five items meet the Definition of Done. What should the Scrum Master do?

The Scrum Master should facilitate a conversation to clarify what "done" means according to the Definition of Done. The DoD is the objective standard — it's not the Product Owner's subjective judgment. If the items genuinely meet the DoD, they are part of the Increment regardless of the Product Owner's preference. The Scrum Master would coach the team to use the DoD as their reference point.

Scenario 2: Halfway through a Sprint, a senior stakeholder contacts the Developers directly and asks them to add a critical bug fix to the Sprint Backlog. What is the Scrum Master's role?

The Scrum Master protects the Sprint. Stakeholders don't interact with Developers directly outside of designated events. The Scrum Master would redirect the stakeholder to the Product Owner, who can assess the priority and, if necessary, negotiate scope changes with the Developers — while preserving the Sprint Goal.

Scenario 3: The team has been working without a Product Goal for three Sprints. The Product Backlog is large, unordered, and growing in all directions. What should the Scrum Master do?

This is a coaching opportunity. The Scrum Master would facilitate conversations — possibly including a Product Goal workshop — to help the Product Owner articulate a clear, meaningful Product Goal. Without it, the team lacks direction and the Product Backlog loses coherence. This is a transparency failure, and addressing it is squarely within the Scrum Master's servant leadership responsibilities.

---

Key Takeaways

• The three Scrum artifacts are the Product Backlog, the Sprint Backlog, and the Increment
• Each artifact has a corresponding commitment: Product Goal, Sprint Goal, and Definition of Done
• Commitments give artifacts purpose — they prevent them from becoming meaningless documentation
• The Product Owner owns the Product Backlog; the Developers own the Sprint Backlog; the Increment is created by the Developers for the Scrum Team
• The Scrum Master does not own any artifact — they coach and protect the process
• The Definition of Done is not the same as Acceptance Criteria
• Multiple Increments can be created within a single Sprint
• Artifacts support empiricism by making the state of work transparent, enabling inspection and adaptation

---

Conclusion

Mastering artifacts and commitments isn't just about memorizing the framework — it's about understanding the why behind each piece. When you internalize that every artifact exists to create transparency in service of empiricism, and that every commitment exists to give that artifact a purpose, scenario-based questions become much more straightforward to navigate.

The best way to cement this understanding is through deliberate practice with scenario-based Scrum Master questions — the kind that put you inside a real team situation and ask what you'd do, or what went wrong, or who owns the decision. Seek out PSM I practice exams and CSM mock tests that challenge your application of these concepts, not just your recall. That's where the real preparation happens.

---

Frequently Asked Questions

Q: Can the Sprint Goal change during a Sprint?

The Sprint Goal should remain stable throughout the Sprint. The only circumstance under which a Sprint might be cancelled — and the Sprint Goal effectively abandoned — is if the Sprint Goal becomes obsolete, which can be caused by changing business conditions. Only the Product Owner has the authority to cancel a Sprint. Changing the Sprint Goal mid-Sprint without cancelling the Sprint is not aligned with the Scrum framework.

Q: Who is responsible for creating and updating the Definition of Done?

If the organization has an existing Definition of Done, the Scrum Team must use it as a minimum standard and can strengthen it. If no organizational standard exists, the Scrum Team creates their own Definition of Done. The Developers are primarily responsible for adhering to it day-to-day, but the DoD belongs to the entire Scrum Team.

Q: Is the Product Goal written inside the Product Backlog?

Yes. According to the 2020 Scrum Guide, the Product Goal is contained within the Product Backlog. It represents the long-term objective toward which the Scrum Team works, and the rest of the Product Backlog items exist to define what will fulfill the Product Goal or what needs to happen along the way. The Scrum Team pursues one Product Goal at a time, and a new one is set only after the current goal is achieved or abandoned.