What are the Scrum Artifacts?

In Scrum, we have 3 official Scrum artifacts that our Scrum team uses. The Product backlog, the Sprint Backlog, and the Product Increment.

Each one of these has its own commitment made by the team.

• For the Product Backlog, we have the Product Goal.
• For the Sprint Backlog, we have the Sprint Goal.
• For the Product Increment, we have the Definition of Done.

Sounds easy, right, but let's go deeper into the Scrum artifacts.

Product Backlog

The product backlog is an emergent, ordered list of our product to achieve our product goal.

The Product Owner is responsible for the prioritization of the Product backlog items. But needs the Scrum Teams to refine the product backlog items.

With refining, we mean sizing, clarifying, and ordering the product backlog. This is an ongoing process but can be forgotten easily. Making the sprint planning harder to keep in the timebox.

Therefore you can introduce a new unofficial sprint event. The product backlog grooming session.

Commitment: Product goal

The product goal is a description of the future state of our product. The product goal serves as a target for the scrum team to plan their work against. It helps them to create better Sprint Goals in line with the Product Goal.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

-- Scrum Guide

The product goal is the long-term objective for the Scrum Team to deliver value to their customers.

Sprint Backlog

The sprint backlog is a list of work to be done in the Sprint timebox to reach the Sprint Goal.

The sprint backlog is composed of the following:

• The Sprint Goal (why)
• Product Backlog items selected for the sprint (what)
• A plan to create a product increment (how)

The sprint backlog is a plan made by the Development Team for the Development Team.

It is a highly visible and real-time picture of the work that the Development Team needs to complete to reach the Sprint Goal and deliver a valuable product increment.

The sprint backlog is created during the Sprint Planning meeting but is not written in stone there and then. The only thing that the team commits themselves to is the Sprint Goal. This cannot change during the sprint.

The plan to reach the Sprint Goal is updated throughout the sprint. It should contain enough detail so that the Development Team can inspect their progress during the Daily Scrum meeting.

Commitment: Sprint Goal

The Sprint Goal is the only objective the scrum team needs to reach during their Sprint. The Sprint Goal is the only thing that cannot change during the sprint.

It is a commitment made by the developers. But don't be fooled. The Sprint Goal provides flexibility to the team in terms of the exact work that is needed to achieve the Sprint Goal.

It creates focus and coherence, encouraging the Scrum Team to work together on different initiatives.

The Sprint Goal is created during the Sprint Planning meeting and added to the Sprint Backlog.

The Goal must be visible at all times when someone looks at the Sprint Backlog. This helps the developers keep the Sprint Goal in mind when they inspect their work during the Sprint.

If the work turns out different than expected, which happens from time to time in complex environments, the Development Team collaborates with the Product Owner to negotiate the scope of the Sprint Backlog without changing the Sprint Goal.

If you need to change the Sprint Goal, you'll need to cancel your current Sprint and start a new one.

Product Increment

A Product Increment is a stepping stone toward the Product Goal.

Each Product Increment is additive to all the previous ones. They work together and are thoroughly verified. To provide value, the Product Increment must be usable.

During the Sprint, the team can release multiple Product Increments.

During the Sprint Review, the sum of all Increments is presented to the Stakeholders. The Increment can be delivered before the Sprint Review. The Sprint Review should not be considered a gate to release value.

A Product Increment is complete when it meets the Definition of Done.

Commitment: Definition of Done

The Definition of Done is a description of the state of the Product Increment. It defines the quality criteria for our product.

The moment a Product backlog item meets the Definition of Done, a Product Increment is born.

The Definition of Done gives everyone a shared understanding of the work to be done for Product Backlog Items.

If a Product Backlog Item does not meet the Definition of Done, it cannot be considered a Product Increment and cannot be released or shown at the Sprint Review. It returns back to the Product Backlog to be completed in a future sprint.

If the Definition of Done is an organizational standard, all Scrum Teams must follow it as a minimum. If there is no Definition of Done in the organization, the Scrum Team creates on its own.

If there are multiple Scrum Teams working on the same product. They must mutually define and comply with the same Definition of Done.

The Definition of Done changes over time while the scrum teams inspect their work and adapt to create a more quality product.

FAQ

Does each Scrum Team need a Definition of Done?

Yes, each team must have a Definition of Done. If they work on the same product, they should all comply with a shared Definition of Done that is created in collaboration between the teams.

Can a Sprint Goal change during the sprint?

No, during the sprint, you cannot change the Sprint Goal. If that is your only option you should cancel the current Sprint and start a new one.

Can you change the sprint backlog during the sprint?

Yes, you can change the Sprint Backlog during the sprint. The only thing you cannot change during the sprint is the Sprint Goal.

Who creates the Product Goal?

The Product Goal should be created by the Scrum Team in collaboration with the Stakeholders. I repeat, in collaboration with the Stakeholders.

Can you release multiple times during a Sprint?

Yes, Scrum requires you to release at least one Product Increment during the Sprint. I encourage you to release when a Product Increment is born and not wait until the end of the sprint.

Can I add Product Backlog items to the Product backlog?

If you are the Product Owner, you can always add Product Backlog items. If you are working in the Scrum Team you should do it collaboratively with the Product Owner, which is the person responsible for the Product Backlog. The Product owner decides where the Product Backlog items will be placed on the Product Backlog.

Who estimates the Product Backlog Items?

The people doing the work estimate the Product Backlog Items. This can be done during a Product Backlog Refinement session or asynchronously during the Sprint.

Why should we estimate our work?

It creates transparency for the Product Owner that an item is ready to be worked on or not. Some Product Backlog items can be too vague or just too big to start working on.

It also creates velocity for the Scrum Team, giving the Product Owner the chance to forecast future work.

When should a Sprint Goal be created?

The Sprint Goal should be created in the Sprint Planning meeting.

Should the Scrum Master update the Sprint Backlog?

No, it is the responsibility of the people during the work to keep their Sprint Backlog up to date. The Scrum Master should coach the people doing the work to keep their Sprint Backlog a real-time document.

Who decides how much work will be done during the Sprint?

The Scrum Team decides how much work will be done during the Sprint. This happens during the Sprint Planning meeting, where they select Product Backlog items from the Product Backlog. Create a Sprint Goal and then create a plan to reach this Sprint Goal.

How can we inspect our progress during the Spring?

You can use a sprint burndown chart. This signals the sprint progress.