Key takeaways
- Scrum has three artifacts: the Product Backlog, the Sprint Backlog and the Increment.
- Each artifact has a commitment: the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog and the Definition of Done for the Increment.
- Artifacts are designed to maximize transparency of key information.
- Work cannot be considered part of an Increment unless it meets the Definition of Done.
- The Product Owner is accountable for the Product Backlog; the Developers own the Sprint Backlog.
Three artifacts, three commitments
Scrum artifacts represent work or value. They are designed to maximize transparency of key information, so that everyone inspecting them has the same basis for adaptation. Since the 2020 Scrum Guide, each artifact contains a commitment that provides focus and lets progress be measured.
| Artifact | Commitment | Owner | Question it answers |
|---|---|---|---|
| Product Backlog | Product Goal | Product Owner | What could we do to improve the product? |
| Sprint Backlog | Sprint Goal | Developers | What will we do this Sprint, and why? |
| Increment | Definition of Done | Scrum Team | What have we really finished? |
Product Backlog and 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 at the top are usually clearer and more detailed, so that they can be done within one Sprint.
Its commitment is the Product Goal: a future state of the product that serves as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog; the rest of the Product Backlog emerges to define "what" will fulfill it. The Scrum Team must fulfill or abandon one Product Goal before taking on the next.
Example. Product Goal: "Students can prepare for and book their exam entirely from their phone." The Product Backlog then contains items such as a mobile booking flow, offline study mode or payment by mobile wallet.
Sprint Backlog and Sprint Goal
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what) and an actionable plan for delivering the Increment (how). It is a plan by and for the Developers, a highly visible, real-time picture of the work they plan to accomplish during the Sprint. It is updated throughout the Sprint as more is learned.
Its commitment is the Sprint Goal, the single objective for the Sprint. It is created during Sprint Planning and does not change during the Sprint. It provides flexibility on the exact work needed to achieve it and encourages the Scrum Team to work together rather than on separate initiatives.
Increment and 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, ensuring that all Increments work together. To provide value, the Increment must be usable. Multiple Increments may be created within a Sprint, and an Increment may be delivered to stakeholders before the end of the Sprint.
Its commitment is the Definition of Done: 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. Work that does not meet it cannot be released or even presented at the Sprint Review; it returns to the Product Backlog.
If the Definition of Done is part of the standards of the organization, all Scrum Teams must follow it as a minimum. Otherwise, the Scrum Team must create one appropriate for the product.
Why artifacts matter: transparency
Scrum relies on empiricism: decisions are only as good as the information they are based on. If artifacts are not transparent (an unclear Product Backlog, a Sprint Backlog nobody updates, a vague Definition of Done), inspection becomes misleading and adaptation goes in the wrong direction. Keeping the three artifacts transparent is a shared responsibility of the whole Scrum Team.
Continue with the 5 Scrum events, or look up any term in the Scrum Glossary.
Frequently asked questions
Sources
- Ken Schwaber and Jeff Sutherland, The Scrum Guide, November 2020.
- Manifesto for Agile Software Development, 2001.
- SCRUM Framework, How our certification exams work.
Exam content is based on the Scrum Guide by Ken Schwaber and Jeff Sutherland, licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). SCRUM Framework is an independent certification body. It is not affiliated with, endorsed by or sponsored by Scrum.org, Scrum Alliance or Scrum Inc., whose names and trademarks belong to their respective owners.
