Scrum Master Exam Guide: Artifacts and Commitments Explained

If you've been studying for the PSM I or CSM exam, you've probably noticed that the 2020 Scrum Guide made one particularly significant structural change: it introduced formal commitments for each of the three Scrum artifacts. This wasn't just cosmetic housekeeping. It was a deliberate design decision to reinforce transparency, focus, and accountability across the entire Scrum framework. Understanding why those commitments exist — not just what they are — is exactly the kind of depth that separates candidates who pass from those who struggle.

The artifact-commitment pairing is one of the most frequently tested areas on both the Professional Scrum Master I (PSM I) from Scrum.org and the Certified ScrumMaster (CSM) from Scrum Alliance. Questions in this domain tend to be tricky because they test conceptual understanding, not memorization. You'll face scenarios where you need to decide what a Scrum Master should do, what belongs in which artifact, or who is responsible for maintaining transparency. Getting these right requires building a mental model that connects the artifacts, their commitments, and the values that underpin them.

This guide walks you through everything you need to know about Scrum artifacts and their commitments — grounded in the 2020 Scrum Guide, enriched with real-world context, and specifically framed to help you think the way exam questions expect you to think.

---

Introduction to Scrum Artifacts and the 2020 Commitments

Scrum artifacts represent work or value. That's not just a textbook definition — it's the operational heart of how Scrum teams create transparency about what they're building, why they're building it, and whether the work actually meets the expected standard of quality.

The three artifacts are:

• Product Backlog — representing the totality of work anticipated for the product
• Sprint Backlog — representing the plan for the current Sprint
• Increment — representing the usable, potentially releasable product built during a Sprint

What the 2020 Scrum Guide added was a formal commitment for each artifact:

• Product Backlog → Product Goal
• Sprint Backlog → Sprint Goal
• Increment → Definition of Done

Think of commitments as the "why" and "what standard" behind each artifact. They give the artifacts direction and measurability. Without the Product Goal, the Product Backlog is just a wish list. Without the Sprint Goal, the Sprint Backlog is a disconnected collection of tasks. Without the Definition of Done, the Increment has no quality standard and no meaningful definition of "finished."

From a servant leadership standpoint, a great Scrum Master helps the team internalize these commitments — not enforce them from the top, but genuinely understand why they matter. When teams truly connect with their Sprint Goal, for example, they make better decisions during the Sprint without needing to run every question up the chain.

---

The Product Backlog and the Product Goal

What the Product Backlog Actually Is

The Product Backlog is an emergent, ordered list of everything needed to improve the product. It's owned by the Product Owner, who is accountable for its content, ordering, and transparency. Notice the word "accountable" — Scrum doesn't say the Product Owner is the only person who can add to the Backlog, but they are ultimately responsible for it.

The Backlog is never truly "done" — it evolves as the product evolves, as customer needs change, and as the team learns. This concept of emergence is important for exam questions. If you see an answer that suggests the Product Backlog should be fully defined upfront, it's wrong.

The Product Goal: The Commitment That Gives the Backlog Purpose

The Product Goal describes the future state of the product and serves as the long-term objective for the Scrum Team. Every item in the Product Backlog should exist in service of that goal — or be irrelevant and removed.

Here's a real-world way to think about it: imagine you're a Scrum Master working with a team building a mobile banking app. The Product Goal might be something like "Enable customers to manage all their financial accounts through a single, secure mobile platform by Q3." Now, when stakeholders start adding feature requests that have nothing to do with that goal — say, a social sharing feature for transactions — the Product Goal becomes your most powerful tool for a productive conversation. It's not about saying no; it's about asking "does this serve where we're going?"

The 2020 Scrum Guide states that the Scrum Team must fulfill (or abandon) one Product Goal before pursuing the next. This sequential focus is often tested on the PSM I. You won't see Scrum teams juggling three simultaneous Product Goals — that would undermine focus and create a lack of transparency.

Exam mindset tip: If a question asks who is responsible for the Product Goal, the answer is the Product Owner. If it asks who is accountable for the Increment meeting the Definition of Done, don't confuse that with artifact ownership. Stay clear on "accountable for what" versus "who owns what."

---

The Sprint Backlog and the Sprint Goal

Understanding the Sprint Backlog's Three Components

The Sprint Backlog is often misunderstood as just "the list of tasks for the Sprint." The 2020 Scrum Guide is more precise: it consists of three elements:

1. The Sprint Goal (why the Sprint exists)
2. The selected Product Backlog items (what will be built)
3. An actionable plan (how the work will be accomplished)

This three-part structure matters for the exam because questions sometimes test whether you understand the Sprint Backlog as a planning tool versus just a task board. The Sprint Backlog is created during Sprint Planning and is owned exclusively by the Developers. Not the Product Owner. Not the Scrum Master. The Developers.

The Sprint Goal: North Star for the Sprint

The Sprint Goal is the single objective for the Sprint. It provides coherence and focus. It's the reason the team is doing this particular Sprint, and it gives Developers the flexibility to negotiate scope without losing direction.

That last point is critical and frequently tested. If something unexpected happens mid-Sprint — a dependency breaks, a technical discovery changes the approach — the team can adapt how they deliver the Sprint Goal without abandoning the goal itself. The goal is the commitment; the specific Backlog items are the current best plan to achieve it.

As a Scrum Master, you protect the Sprint by helping the team stay anchored to the Sprint Goal. When a stakeholder approaches mid-Sprint with a "quick" new request, your job isn't to say "rules say no." Your job is to help the team evaluate whether that request threatens the Sprint Goal and to facilitate the right conversation. If it doesn't threaten the goal, the Developers can decide to take it on. If it does, it goes to the Product Backlog and gets considered in the next Sprint.

Real-world scenario: A development team is three days into a Sprint when the CTO asks them to also fix a critical security vulnerability. As the Scrum Master, you don't just shield the team and say no. You bring the issue to the Product Owner, help assess whether the Sprint Goal can still be met, and if necessary, support a conversation about whether to cancel the Sprint or adjust scope. This is servant leadership in action — not blind rule enforcement, but thoughtful facilitation in service of the goal.

---

The Increment and the Definition of Done

What Makes an Increment an Increment

An Increment is a concrete stepping stone toward the Product Goal. Each Sprint must produce at least one Increment — and it must be usable, meaning it could theoretically be released (even if the decision to release isn't made). Multiple Increments can be created within a Sprint, and they can be delivered to stakeholders before the Sprint Review.

One important nuance: work that doesn't meet the Definition of Done cannot be called an Increment. It cannot be presented at the Sprint Review as Done work. This has real consequences — if a team is regularly not meeting the Definition of Done, the Scrum Master needs to address the structural or organizational impediments making that happen.

The Definition of Done: Quality as a Commitment

The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the product. It creates shared understanding across the Scrum Team and ensures transparency about what "done" actually means.

If there is an organizational Definition of Done, the Scrum Team must comply with it as a minimum. The team can then make their own DoD more rigorous, but they cannot make it less demanding than the organizational standard. This is a common exam trap — teams can only expand the DoD, never weaken it.

Who owns the Definition of Done? This is where candidates often get tripped up. The Scrum Team creates and owns the DoD. It's not the Product Owner's definition, and it's not the Scrum Master's list of quality gates. It's a collaborative agreement. However, if no organizational standard exists, the Scrum Team must create one themselves.

Exam mindset tip: The Definition of Done is not the same as acceptance criteria. Acceptance criteria are specific to individual Product Backlog items. The Definition of Done applies to every Increment, every time, without exception.

---

How Commitments Enhance Transparency and Focus

One of Scrum's foundational pillars is transparency — making the significant aspects of work visible to those responsible for the outcomes. The commitments directly serve this pillar.

Without the Product Goal, the Product Backlog can become a graveyard of half-baked ideas with no strategic direction. Without the Sprint Goal, a Sprint can turn into a sprint to ship features with no coherent purpose. Without the Definition of Done, "done" means something different to every person in the room — which is a transparency failure.

The commitments also serve focus, another core Scrum value. When everyone on the team understands the Sprint Goal, they make micro-decisions throughout the Sprint that align with it. They don't need to check in for every small decision because the goal itself provides direction. This is self-management made practical.

From a Scrum Master's perspective, one of the most valuable things you can do is consistently bring the team back to these commitments during Scrum events. In the Daily Scrum, are the Developers discussing their work in the context of the Sprint Goal? In Sprint Planning, is the team genuinely deriving the Sprint Goal from the Product Goal — or just listing tasks? In the Sprint Retrospective, did the team actually meet their Definition of Done, and if not, what needs to change?

---

Common Exam Questions on Artifact Ownership

Ownership questions are consistently among the trickiest on the PSM I. Here's a clear breakdown:

• Product Backlog → owned and maintained by the Product Owner
• Sprint Backlog → owned by the Developers
• Increment → the entire Scrum Team is accountable, but Developers build it

Common traps to watch for:

• The Scrum Master does not own any artifact
• The Product Owner does not have authority over the Sprint Backlog after Sprint Planning
• Stakeholders can observe Sprint events but don't control the artifacts
• The Product Owner is the only one who can cancel a Sprint — not the Scrum Master, not the Developers

A typical exam scenario might say: "The Product Owner wants to add three new items to the Sprint Backlog mid-Sprint. What should the Scrum Master do?" The correct approach involves facilitating a conversation between the Product Owner and Developers, not simply refusing the request or complying without discussion. The Developers own the Sprint Backlog and can negotiate scope — but they do so in the context of protecting the Sprint Goal.

---

Key Differences Between Artifacts and Commitments

It's worth being crystal clear on this distinction because exam questions sometimes conflate the two:

Artifact	Commitment	Owner of Artifact	Owner of Commitment
Product Backlog	Product Goal	Product Owner	Product Owner
Sprint Backlog	Sprint Goal	Developers	Developers (created collaboratively in Sprint Planning)
Increment	Definition of Done	Scrum Team	Scrum Team

Key conceptual differences:

• Artifacts represent work or value in a tangible form
• Commitments provide the standard, direction, or purpose against which the artifact is measured
• Commitments exist to increase transparency and enable inspection and adaptation
• Commitments are not optional enhancements — they're required elements of the framework

---

Study Tips for the PSM I and CSM Artifact Domain

Ground Everything in the 2020 Scrum Guide

Both PSM I and CSM exams are based on the 2020 Scrum Guide. If you're referencing older materials, YouTube videos, or third-party prep courses that reference earlier versions, you may be learning outdated content. The introduction of formal commitments is one of the key 2020 changes — make sure your prep materials reflect this.

Practice Scenario-Based Thinking

The hardest questions are not "what is the Definition of Done?" — they're "A team just finished a Sprint but two items didn't meet the Definition of Done. What happens?" Learn to reason through scenarios using Scrum principles, not just definitions.

Use Active Recall

Instead of re-reading notes, quiz yourself: Without looking, what are the three artifacts? What is each commitment? Who owns each one? What happens if no organizational DoD exists? This kind of active retrieval builds the durable memory you need under exam pressure.

Connect Values to Mechanics

Scrum's five values — Commitment, Focus, Openness, Respect, and Courage — underpin every practice. When you understand why the Sprint Goal exists (it creates Focus and Commitment), you'll answer exam questions more confidently than someone who just memorized the definition.

---

Key Takeaways

• The 2020 Scrum Guide introduced three formal commitments, one per artifact: Product Goal (Product Backlog), Sprint Goal (Sprint Backlog), and Definition of Done (Increment)
• Commitments exist to increase transparency and focus — they're not optional add-ons
• The Product Owner owns the Product Backlog and Product Goal; Developers own the Sprint Backlog; the entire Scrum Team is accountable for the Increment meeting the Definition of Done
• Work that doesn't meet the Definition of Done is not an Increment and cannot be presented at the Sprint Review as Done
• The Sprint Goal gives Developers flexibility to negotiate scope while maintaining direction
• Teams can make their DoD more rigorous than organizational standards — but never less
• The Scrum Master's role around artifacts is facilitative, not ownership-based

---

Conclusion

Artifacts and their commitments might seem like a narrow topic, but they touch nearly every aspect of how Scrum teams operate — from how they plan, to how they adapt, to how they define quality. Getting this domain right on your PSM I or CSM exam means understanding the relationships, the ownership, and the purpose behind each pairing.

The best way to solidify this knowledge is to move beyond reading and start practicing with scenario-based Scrum Master questions that simulate real exam conditions. When you encounter a tricky question about whether a Scrum Master should intervene when the Sprint Goal is under threat, or what happens when a team ships an Increment without meeting the DoD, your answer should come from a deep understanding of why the framework is designed the way it is — not from a memorized list.

---

Frequently Asked Questions

Q: Can a Scrum Team have more than one Sprint Goal at a time?

No. The Sprint Goal is a single objective for the current Sprint. Having multiple Sprint Goals would undermine focus and create conflicting priorities for the Developers. If there are multiple objectives that can't be unified under one coherent goal, that's a signal to revisit Sprint Planning or the Product Goal itself.

Q: Who is responsible for creating the Definition of Done if the organization doesn't have one?

The Scrum Team creates the Definition of Done themselves. It's a shared agreement among all members of the Scrum Team about what quality standard the Increment must meet. The Scrum Master may facilitate that conversation, but the DoD belongs to the whole team — not just Developers or the Product Owner alone.

Q: What should a Scrum Master do if the team regularly fails to meet the Definition of Done by Sprint end?

This is a systemic issue, not just a performance problem. The Scrum Master should investigate whether the DoD is unrealistic for current team capacity, whether there are organizational impediments (technical debt, lack of testing infrastructure, unstable dependencies), or whether Sprint Planning is consistently over-committing. The Sprint Retrospective is the formal venue for this conversation, but the Scrum Master should be facilitating the team's self-management around this issue continuously — not waiting until it becomes critical.