Scrum Artifacts and Commitments

Artifacts and their commitments

A Scrum artifact represents work or value. The Scrum Guide says the artifacts are designed to "maximize transparency of key information", so that everyone who inspects them has the same basis for adaptation. In Scrum, important decisions are based on the state of the artifacts; if they are vague or out of date, those decisions suffer.

Since 2020, each artifact contains a commitment: a goal or standard that gives the artifact focus and against which progress can be measured. The commitments exist "to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders".

The Product Backlog

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work for the Scrum Team. Each word matters:

• Emergent: it is never finished. Items are added, changed and removed as the team and its stakeholders learn.
• Ordered: every item has a place in one sequence. The Product Owner decides the order, weighing value, risk, dependencies and learning, not only a "priority" label.
• Single source of work: work that is not in the Product Backlog does not get done by the Scrum Team. A second, hidden list in a manager's spreadsheet undermines transparency.

Items that can be Done within one Sprint are "deemed ready for selection" in Sprint Planning. They usually reach that point through refinement: the ongoing activity of breaking items down and adding detail such as a description, order and size. The Developers who will do the work are responsible for sizing. How to write, split and order items is covered in Product Backlog Management.

Kestrel customer portal and app · Product Backlog (top of the list)

Product Goal: Before the end of the winter, customers can handle an
outage and a meter reading entirely in the app: calls to customer
service about these two topics drop by at least 30% compared to last
winter.

Order  Item                                                    Size
  1    PBI-412  Submit a meter reading in the app                5
  2    PBI-415  Show the new reading in the bill estimate        3
  3    PBI-398  Attach a photo of the meter as proof             8
  4    PBI-431  Outage notifications in the app                  8
  5    PBI-377  Dark mode in the app                             2
 ...
 58    PBI-140  Export usage history to a spreadsheet            ?

The sizes here are story points, a relative unit many teams use. That is a common practice, not part of Scrum; the guide only says items have a size and that the Developers decide it.

The Product Goal

The Product Goal describes a future state of the product that the Scrum Team can plan against. It is the long-term objective for the Scrum Team and the commitment of the Product Backlog: it lives in the Product Backlog, and the rest of the backlog emerges to define "what" will fulfill it.

The team works toward one Product Goal at a time. The guide says it must "fulfill (or abandon) one objective before taking on the next". A goal can be abandoned when the team learns that it is no longer worth pursuing; that is empiricism, not failure.

The guide defines a product as "a vehicle to deliver value" with a clear boundary, known stakeholders and well-defined users or customers. A product can be a service, a physical product or something more abstract, close to the ITIL idea of a product. Kestrel's customer portal and app together form one product with one Product Backlog.

The Sprint Backlog

The Sprint Backlog is made up of three parts: the Sprint Goal (why), the 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": they create it in Sprint Planning, they own it, and they update it throughout the Sprint as they learn more. It should have enough detail for the Developers to inspect their progress in the Daily Scrum.

Because the Sprint Backlog belongs to the Developers, nobody else adds tasks to it or assigns them. The Product Owner influences what is selected and can renegotiate scope with the Developers; the plan for how is theirs alone.

Portal team · Sprint 23 · Sprint Backlog (day 6 of 10)

Sprint Goal
  Customers can submit a meter reading in the app and see its effect on
  their next bill estimate.

Selected Product Backlog items                Status
  PBI-412  Submit a meter reading in the app    in progress
  PBI-415  Show the reading in the estimate    in progress
  PBI-398  Attach a photo of the meter          not started
  PBI-420  Fix rounding in the kWh display      Done

Plan (updated daily by the Developers)
  [x] API endpoint for readings                          Ravi
  [x] Reject readings lower than the previous one        Kwame
  [ ] App screen with a number pad                       Sofia
  [ ] Accessibility check of the new screen              Priya
  [ ] Index on the readings table for the estimate       Bram
  [ ] Load test: 2,000 submissions per minute            Priya, Ravi

On day 6, the team sees that the meter photo (PBI-398) will not fit. The Sprint Goal does not depend on it, so the Developers agree with Isabel, the Product Owner, to move it back to the Product Backlog. The scope changed; the goal did not.

The Sprint Goal

The Sprint Goal is the single objective for the Sprint and the commitment of the Sprint Backlog. The whole Scrum Team creates it during Sprint Planning, and it is then added to the Sprint Backlog. It is a commitment by the Developers, but it deliberately leaves flexibility in the exact work needed to reach it.

That flexibility is the point. A Sprint Goal turns a list of items into one shared purpose, so that the team works together instead of on separate tasks, and it tells the Developers what to protect when things go differently than expected. If the work turns out to be different, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog without affecting the Sprint Goal.

Sprint 23 — Customers can submit a meter reading in the app and see
its effect on their next bill estimate.

Compare that with "Finish PBI-412, PBI-415 and PBI-398". The second version is a to-do list: it gives no reason, and when one item turns out to be hard, nothing says which of the others matters most.

The Increment

An Increment is a concrete stepping stone toward the Product Goal. Each Increment adds to all previous Increments and is thoroughly verified, so that all of them work together. To provide value, an Increment must be usable: a customer could use it, whether or not it has been released yet.

• An Increment is born when an item meets the Definition of Done. In the guide's words: "The moment a Product Backlog item meets the Definition of Done, an Increment is born."
• Several Increments per Sprint are possible. The sum of the Increments is presented at the Sprint Review.
• Releasing does not wait for the Sprint Review. An Increment may be delivered to stakeholders before the end of the Sprint; the guide says the Sprint Review should never be considered a gate to releasing value. Teams with continuous delivery and feature flags release many times per Sprint.
• Not Done means not part of the Increment. Work that does not meet the Definition of Done cannot be released or even presented at the Sprint Review. It returns to the Product Backlog for future consideration.

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. It is the commitment of the Increment. It creates transparency: everyone, inside and outside the team, shares one understanding of what "Done" means, so "almost done" or "done except testing" cannot hide in a status report.

Who creates it depends on the organization:

• If the Definition of Done is part of the organization's standards, all Scrum Teams must follow it as a minimum, and they can add to it.
• If it is not an organizational standard, the Scrum Team must create one that is appropriate for the product.
• The Developers are required to conform to it.
• When several Scrum Teams work on the same product, they must define and comply with the same Definition of Done together.

The Definition of Done is inspected in every Sprint Retrospective, and mature teams tend to make it stricter over time: each step that moves from "after the Sprint" into the Definition of Done is one less surprise at release time.

Example: the Portal team's Definition of Done

Definition of Done — Kestrel customer portal and app

Kestrel organizational minimum (every Scrum Team)
  - Code reviewed by at least one other Developer and merged to main
  - All automated tests pass in the pipeline
  - No new critical or high findings in the security scan
  - Personal data handled according to Kestrel's privacy policy (GDPR)
  - Change recorded according to Kestrel's change enablement practice

Portal team additions
  - Unit and integration tests written for new behavior
  - Works in the current versions of the major browsers and in the
    iOS and Android app
  - Every changed screen meets WCAG 2.2 level AA
  - Load test passed for flows that customers use at peak times
  - Deployed to the acceptance environment and smoke-tested
  - User-facing text available in Dutch and English
  - Release notes and service desk knowledge articles updated

Note what is not in it: business-specific checks for one item, such as "the estimate uses the new reading". Those belong in that item's acceptance criteria, a common practice described in Product Backlog Management. The Definition of Done applies to every item; acceptance criteria apply to one. Quality in Agile Teams shows how the Portal team turns an escaped bug into new, checkable lines. The change record links Scrum to change enablement: the Definition of Done is a good place to make the agreed change practice part of normal work.

What the guide does not prescribe

Teams surround the three artifacts with many other tools. Most are useful; none is required by Scrum.