Scrum’s artifacts represent work or value. They’re are designed to maximize transparency of key information.
Each artifact contains a commitment to ensure it provides information hat enhances transparency and focus against which progress can be measured.
| Artifact | Commitment | Person accountable |
|---|---|---|
| Product Backlog | Product Goal | Product Owner |
| Sprint Backlog | Sprint Goal | Entire Scrum Team |
| Increment | Definition of Done | Entire Scrum Team |
These commitments exist to reinfoce empiricism and the Scrum values for the Scrum Team and its stakeholders.
The Definition of Done is an artifact. It wasn’t in past versions, but it is now.
The commitments for each Scrum Artifact are mandatory. The person who is accountable for the artifact, is accountable for the commitment too.
The use of the word commitment when describing each artifact is similar in that a team commits to provide for his artifact a Product Goal, Sprint Goal, or Definition of Done.
Each Scrum Artifact is designed to maximize transparency or key information.
The Product Backlog
The Product Backlog is a list of ordered items. It’s the single source of work. This list is ordered by the Product Owner, in a way that maximizes the value the product delivers. The items that bring most value go on top of the list, because then the developers would select as many as they believe they can get done during the Sprint. If one item is too big to fit in one Sprint, we have to break it down into smaller items. These items have to be clear, by adding details such as description, size (Story Points) and order. This process is called Product Backlog Refinement.
The developers are responsible for sizing the Stories.
The Product Backlog is never complete. It’s a dynamic artifact and it evolves constantly. Since it’s never complete, the Scrum Team does not wait for completion before starting the first Sprint.
On average, the items on top of the Product Backlog are smaller than the ones at the bottom.
A Product is a vehicle o deliver value. I has a clear boundary, known sakeholders, well-defined users or cusomers. A product could be a service, a physical product, or something more abstract. It’s not about the product itself, it’s about the value it delivers, the benefits it delivers to end users.
The Product Goal
The Product Backlog contains the commitment: The Product Goal.
The Procuct Goal describes a future state of the product whih can serve 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 the Product Goal.
The Product Goal helps the team stay focused. The guide sates that we cannot have two or more Product Goals at the same time. The Scrum Team must fulfill or abandon one objective before taking on the next.
The Product Owner is accountable for the Produt Goal as well as the Product Backlog.
One of the accountabilities of the Product Owner is developing and explicitly communicating the Product Goal.
- To achieve the Product Goal, it’s not required to complete all stories in the Product Backlog.
- Each increment moves the Product toward the Product Goal.
- It’s recommended that the Product Goal is clear and concise.
- The Product Goal is measurable, the Scrum Team knows when the goal has been achieved.
The Product Goal changes. The more we work, the more we learn. We might discover information tha invalidates the Product Goal and we have to pivot in this case. The Product Goal can only be changed during a Sprint, if the Sprint is cancelled.
The Sprint Backlog
The Sprint Backlog consists of: The Sprint Goal, the Stories selected for the Sprint and an acionable plan for delivering the increment.
The Sprint Backlog is created during the SPrint Planning even, but it’s not with a fixed scope. It’s not frozen. It changes. We can remove stories as long as that will help the team achieve the SPrint Goal. The Sprint Backlog is updated throughout the Sprint as more is learned. The Sprint Backlog is highly visible. The Developers should be able to explain how they plan to accomplish this goal.
The Developers own the Sprint Backlog. In the context of Scrum, to own something, means to be responsible / accountable for it.
The Developers tracks the total remaining work in the Sprint Backlog.
The Sprint Backlog may include process improvements the team identified during the previous Spring Retrospective event.
If a Sprint ends and there are uncomplete Stories, we move them back into the Product Backlog for future considerations. We do NOT move them o the next Sprint Backlog. The reasoning for this is we need to consider if they’re still relevant. We do not include the Stories in the Increment as they’re not ready.
The Sprint Goal
The Sprint Goal is the single objective for the Sprint. The SPrint Goal is mandatory. Each SPrint has a Goal. The entire Scrum Team creates the Sprint Goal during Sprint Planning. It helps the team stay focused during the Sprint.
The Developers can collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting it. Remember we are NOT allowed to change the Sprint Goal. If it becomes obsolete, then the Product Owner cancels the whole SPrint.
The Increment
An Increment is a concrete stepping stone toward the Product Goal. We build the Product one increment at a time and an Increment is additive to all prior increments.
We can create one or a few Increments at a time per Sprint. What’s important is to remember that we combine these increments and we present them during the Sprint Review event. Scrump does not tell us when or how often we need to release. We can release at any time we want. This may be prior to the end of the Sprint, in the middle, or afterwards. The Sprint Review should never be considered a gate to release value. The entire Scrum Team decides when to release an Increment.
An increment is new functionality, that’s in a usable state, complete, and added to the Product.
The Definition of Done
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The DoD is NOT an artifact. It’s a commitment for an artifact (The Increment). Think of the DoD as a checklist. These are all the points that the Team needs to check off to say an item is really done. It means that the item is usable by end users.
The moment a Product Backlog Item meets the Definition of Done, an Increment is Born. This gives us more transparency.
We discuss the Definition of Done in the Sprint Retrospective event.
When we have multiple Scrum Teams working on the same prodct, we have one Product Backlog, one Product Owner and one Product Goal.