A Scrum primer · Part 4 of 5

The Scrum artifacts and their commitments

The Product Backlog, the Sprint Backlog and the Increment, the commitment that goes with each one, and the refinement work that keeps the backlog ready.

What an artifact is

A Scrum artifact represents work or value. Scrum has three: the Product Backlog, the Sprint Backlog and the Increment. Their job is transparency. Everybody who inspects them sees the same information, so everybody can base decisions on the same facts.

Each artifact has a commitment. The commitment gives the artifact a direction and a way to measure progress. It also keeps the team honest about what the artifact is for.

Artifact	Commitment	What the commitment answers
Product Backlog	Product Goal	Where is the product going in the long term?
Sprint Backlog	Sprint Goal	Why does this Sprint matter?
Increment	Definition of Done	When is a piece of work really finished?

The Product Backlog

The Product Backlog is an ordered list of what the product needs. It is the single source of work for the Scrum Team. If a piece of work is not in the Product Backlog, the team does not do it. The list is emergent, which means it changes as the team and its stakeholders learn more about the product, the market and the users.

The Product Owner is accountable for the order of the list. Items at the top are usually small, clear and well understood. An item is ready for selection in Sprint Planning when the team can make it Done within one Sprint. Items further down can stay large and vague, because the team does not need their detail yet.

The Scrum Guide does not prescribe a format for backlog items. User stories, bug reports, technical tasks and experiments can all be backlog items. What matters is that each item is transparent and that the order reflects value.

The commitment: the Product Goal

The Product Goal describes a future state of the product. It gives the Scrum Team a target to plan against. The Product Goal lives in the Product Backlog. The rest of the backlog emerges to define what the team must build to reach it.

The Product Goal is a long-term objective. The team works toward one Product Goal at a time. It must fulfill the goal or abandon it before it takes on the next one. This rule keeps a product from chasing several directions at once.

Refinement is the work of breaking Product Backlog items into smaller, more precise items. It also adds detail, such as a description, the order and a size. Refinement is an ongoing activity. It is not a Scrum event, and it has no timebox.

The Developers who will do the work are responsible for sizing it. The Product Owner can influence the Developers by helping them understand the trade-offs, but the size is the Developers’ call. The Guide leaves the unit and the technique to the team. Story points, hours, and item counts are all options.

The Sprint Backlog

The Sprint Backlog has three parts:

The Sprint Goal, which is the why.
The Product Backlog items selected for the Sprint, which are the what.
An actionable plan to deliver the Increment, which is the how.

The Developers make the Sprint Backlog, and it is for them. It gives a visible, real-time picture of the work that they plan to do in the Sprint. They update it throughout the Sprint as they learn more. It must hold enough detail for them to inspect their progress at the Daily Scrum.

The commitment: the Sprint Goal

The Sprint Goal is the single objective for the Sprint. The Developers commit to it. The goal gives the team focus and makes the Sprint coherent. Without a goal, a Sprint is a list of unrelated tasks. With a goal, the team works together instead of on separate initiatives.

The Sprint Goal also gives flexibility. The team creates the goal in Sprint Planning and adds it to the Sprint Backlog. If the work turns out to be different from what the team expected, the Developers talk with the Product Owner. Together they change the scope of the Sprint Backlog, but they keep the Sprint Goal. The goal stays fixed, and the exact work can move.

The Increment

An Increment is a concrete step toward the Product Goal. Each Increment adds to all the previous Increments, and the team verifies it thoroughly, so that all Increments work together. An Increment must be usable. If a user cannot use it, it does not deliver value.

A team can create more than one Increment in a Sprint. The team presents the sum of them at the Sprint Review. That review supports empiricism, but it is not a gate. A team can deliver an Increment to stakeholders before the Sprint ends.

Work becomes part of an Increment only when it meets the Definition of Done. Nearly finished work is not part of the Increment, however close it is.

The commitment: the Definition of Done

The Definition of Done states, formally, the quality that the Increment must have. It lists the measures that the product requires before anybody can call work done. When a Product Backlog item meets the Definition of Done, a new Increment exists.

The Definition of Done creates transparency. Everybody knows what “done” means, so everybody can tell which work is inside the Increment. If an item does not meet the Definition of Done, the team cannot release it and cannot present it at the Sprint Review. The item goes back to the Product Backlog, and the team can select it again later.

If the organization has a Definition of Done as a standard, every Scrum Team must follow it as a minimum. If it has none, the Scrum Team must create one that suits the product. The Developers must conform to the Definition of Done. When several Scrum Teams work on one product, they must agree on one shared Definition of Done and all follow it.

Common mistakes with the artifacts

The Scrum Guide does not list these mistakes. They come from common experience with Scrum teams.

Practical advice, not a rule of the Scrum Guide

A backlog that only grows: Every idea goes in, and nothing comes out. The list becomes too long to order, so the order stops meaning anything. Delete items that will never reach the top.
No Product Goal: The team finishes Sprints but cannot say what they add up to. Each Sprint Goal then has nothing to serve.
A Sprint Goal that restates the items: The goal names the selected items, so it gives no guidance when the plan changes.
A Definition of Done on a wiki page: The team wrote it once and nobody checks it. “Done” then means whatever each person thinks it means, and the Increment is not transparent.
Undone work in the review: The team shows items that are almost done at the Sprint Review. Stakeholders assume the work is finished, and the next Sprint inherits hidden work.

This primer follows the 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland and explains it in our own words. Read the Guide itself at scrumguides.org. The Scrum Guide is available under the Creative Commons Attribution-ShareAlike 4.0 license. Scrum.org and Scrum Inc. did not write or review this page.