The Scrum Guide 2020 defines three Scrum artifacts, and each one has a commitment attached: the Product Backlog is committed to the Product Goal, the Sprint Backlog to the Sprint Goal, and the Increment to the Definition of Done. The artifacts make work and value transparent, and the commitments give each artifact a clear purpose against which progress can be measured. If you understand these three pairs, you can answer a large share of artifact questions on the PSM I, PSPO I and CSM exams.
What are the three Scrum artifacts?
Scrum artifacts represent work or value. They exist to maximize transparency of key information, so that everyone inspecting them has the same basis for adaptation. This ties directly to the three pillars of Scrum: transparency, inspection and adaptation. An artifact that is not transparent leads to poor decisions, because you cannot inspect what you cannot see.
The 2020 edition of the Scrum Guide added one commitment to each artifact. The guide describes these commitments as existing to reinforce empiricism and the Scrum values for the Scrum Team and its stakeholders.
Scrum artifacts and commitments at a glance
| Artifact | Commitment | Who is accountable |
|---|---|---|
| Product Backlog | Product Goal | Product Owner (Product Backlog management, including developing and communicating the Product Goal) |
| Sprint Backlog | Sprint Goal | Developers (the Sprint Backlog is their plan, by and for them) |
| Increment | Definition of Done | Developers conform to it; the Scrum Team creates it if the organization does not provide one |
Keep this table in mind for the exam. Many trick questions simply swap the owner of an artifact or pair an artifact with the wrong commitment.
Product Backlog and the Product Goal
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Items near the top are usually clearer and more refined, because they are likely to be picked in the next Sprint Planning.
Product Backlog refinement is the act of breaking down items and adding detail such as description, order and size. It is an ongoing activity, not a Scrum event. The 2020 guide gives no fixed percentage for it; the old "no more than 10% of the Developers' capacity" guideline was removed.
The Product Owner is accountable for Product Backlog management. The Product Owner is one person, not a committee. They may delegate the work of writing or ordering items to others, but they remain accountable.
What is the Product Goal and why was it added in 2020?
The Product Goal describes a future state of the product and serves as a target for the Scrum Team to plan against. It is the long-term objective of the Scrum Team, and the Product Backlog emerges to define "what" will fulfill it.
Before 2020, Scrum had no explicit artifact-level objective above the Sprint Goal. Teams could work Sprint by Sprint without a shared view of where the product was heading. The Product Goal fills that gap: it connects each Sprint Goal to a larger purpose and gives stakeholders something concrete to inspect progress against.
Two exam details matter. First, the Scrum Team works on one Product Goal at a time. Second, they must fulfill (achieve) or abandon one Product Goal before taking on the next.
Sprint Backlog and the Sprint Goal
The Sprint Backlog is composed of three parts: the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). These match the three topics of Sprint Planning: why is this Sprint valuable, what can be Done this Sprint, and how will the chosen work get done.
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work the Developers plan to accomplish during the Sprint. The Developers own it, and they update it throughout the Sprint as more is learned.
How the Sprint Goal gives flexibility
The Sprint Goal is the single objective for the Sprint. It is created during Sprint Planning and added to the Sprint Backlog. Although it is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.
In practice, this means the selected items and the plan can change during the Sprint while the goal stays stable. If the work turns out to be different than expected, the Developers collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint, without changing the Sprint Goal. The Daily Scrum is where the Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.
If the Sprint Goal itself becomes obsolete, only the Product Owner can cancel the Sprint.
Increment and the Definition of Done
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, so that all Increments work together. To provide value, the Increment must be usable.
What "Done" means
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. The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The DoD creates transparency by giving everyone a shared understanding of what work was completed as part of the Increment. It is the quality bar, and the Developers are accountable for instilling quality by adhering to it.
Where the Definition of Done comes from:
- If the organization has a Definition of Done as part of its standards, all Scrum Teams must follow it as a minimum.
- If it does not, the Scrum Team must create a Definition of Done appropriate for the product.
- A team may make its DoD stricter than the organizational standard, but not weaker.
What happens to undone work?
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration. There is no such thing as "almost done" or "90% done" in Scrum: work is either Done or it is not part of the Increment.
Multiple Increments per Sprint
A common misconception is that a Sprint produces exactly one Increment at the end. The 2020 guide states that multiple Increments may be created within a Sprint. The Sprint Review should never be considered a gate to releasing value: an Increment may be delivered to stakeholders before the end of the Sprint. The sum of the Increments is presented at the Sprint Review.
Common exam traps about Scrum artifacts
These are the points that most often catch candidates out on practice tests and real exams:
- Who owns the Sprint Backlog? The Developers. Not the Product Owner and not the Scrum Master. The Product Owner owns the Product Backlog.
- Can the Sprint Backlog change during the Sprint? Yes. The Developers update it as they learn more, and scope can be clarified and renegotiated with the Product Owner. What should not be compromised is the Sprint Goal or quality.
- Can the team lower the organizational DoD? No. An organizational Definition of Done is the minimum. The team can add to it.
- Is a burndown chart an artifact? No. Burndown charts, velocity, story points and user stories are not in the Scrum Guide. They are complementary practices.
- Is there one Increment per Sprint? Not necessarily. Several Increments can be created, and released, within a single Sprint.
- Can undone work be shown at the Sprint Review? No. It goes back to the Product Backlog.
- How many Product Goals at once? One. It must be fulfilled or abandoned before the next.
The best way to check you really know these rules is to answer exam-style questions under time pressure. Try the free PSM practice exam (20 questions, 20 minutes), or, if you are preparing for the Product Owner exam, the Product Owner certification training, where questions on the Product Goal and Product Backlog management come up often.
FAQ
What are the 3 artifacts in Scrum?
The Product Backlog, the Sprint Backlog and the Increment. In the Scrum Guide 2020, each has a commitment: the Product Goal, the Sprint Goal and the Definition of Done respectively.
Who creates the Definition of Done?
If the organization has a Definition of Done, Scrum Teams follow it as a minimum. If not, the Scrum Team creates one appropriate for the product.
Can the Sprint Backlog change during the Sprint?
Yes. The Developers own the Sprint Backlog and update it throughout the Sprint as they learn more. The Sprint Goal stays fixed, and scope can be renegotiated with the Product Owner.
Is the Product Goal an artifact?
No. The Product Goal is the commitment of the Product Backlog artifact. It is the long-term objective of the Scrum Team, and the team works on one at a time.