PSM I Scrum Artifacts, Commitments and the Definition of Done

Scrum has exactly three artifacts, and the Scrum Guide 2020 pairs each one with exactly one commitment: the Product Backlog with the Product Goal, the Sprint Backlog with the Sprint Goal, and the Increment with the Definition of Done. Each artifact contains its commitment, so the Product Goal lives in the Product Backlog, the Sprint Goal is part of the Sprint Backlog, and the Definition of Done describes what every Increment must be.

The pairings are easy to scramble, so anchor them by scope. The widest artifact (everything the product might need) carries the widest commitment (the Product Goal). The plan for one Sprint carries the goal for one Sprint. The thing that is actually built carries the quality bar it must meet. Anything else, such as a "Sprint forecast", a velocity target or a release roadmap, is not a Scrum commitment.

Why artifacts and commitments exist: transparency and focus

Scrum's artifacts represent work or value, and they are designed to maximize transparency of key information. Because everyone inspecting them sees the same information, everyone has the same basis for adaptation. That is the point: artifacts are what empiricism inspects, and inspection is only as good as the transparency behind it.

The commitments add something the raw artifacts lack: focus against which progress can be measured. A list of items tells you what work exists, but not whether the team is getting closer to anything. The Product Goal lets the team and stakeholders measure progress across Sprints; the Sprint Goal lets them judge one Sprint as a whole; the Definition of Done lets anyone tell finished from unfinished. The Scrum Guide says the commitments exist to reinforce empiricism and the Scrum Values for the Scrum Team and its stakeholders.

Read the commitments as focus devices for the Scrum Team itself: they exist so the team can judge its own progress and adapt, which is why each is phrased as an objective or a quality standard rather than as a promise to an outsider. They also work as a set. A quality bar on its own tells you work is finished but not whether it mattered; a goal on its own tells you where you are heading but not whether you have arrived.

How transparency underpins empiricism in general is covered in the lesson on empiricism and the Scrum Values; this lesson stays with the artifacts themselves.

The Product Backlog is an emergent, ordered list of what is needed to improve the product, and it is the single source of work undertaken by the Scrum Team. Each phrase in that definition rules something out:

• Emergent. The list is never complete or frozen. It changes as the team, the market and the users teach everyone more. Items near the top are refined in detail; items further down are expected to stay coarse and to change, and any attempt to make the whole list complete and final up front works against empiricism.
• Ordered. Items are in an order, not merely tagged with priorities. Ordering is part of the Product Owner's accountability; the Product Owner may delegate the work of ordering but remains accountable for it. The order is what Sprint Planning draws from.
• What is needed to improve the product. Features, defects, technical work, experiments and anything else that improves the product all belong in it. It is not a list of the Developers' tasks, and not only a list of stakeholder change requests.
• Single source of work. Whatever kind of work it is, anything kept outside the Product Backlog is invisible to ordering and to inspection, so all of it belongs in the one list.

The single-source rule also scales: when several Scrum Teams build one product, the Scrum Guide says they share one Product Goal, one Product Backlog and one Product Owner. However many teams draw from it, the ordering decision for a product stays with one accountable person, so the teams' work cannot drift apart. Who the Product Owner is and what else that accountability covers is taught in the lesson on the Scrum Team.

Product Backlog refinement is the ongoing act of breaking down and further defining Product Backlog items into smaller, more precise items. It adds details such as a description, order and size; other attributes vary with the domain of work. It is not an event and has no timebox in the Scrum Guide; it happens whenever it is needed.

The Developers who will do the work are responsible for sizing. The Product Owner may influence them by helping them understand the items and select trade-offs (for example, splitting an item or narrowing its scope), but sizing stays with the people who will do the work, because they are the ones who understand what it involves. The Guide prescribes no unit: story points, hours or anything else are team choices, not Scrum rules.

An item is ready for selection in Sprint Planning when the Scrum Team could get it Done within one Sprint. Items usually reach that degree of transparency through refinement. The Scrum Guide has no "Definition of Ready" and does not require user stories or acceptance criteria; teams may use such practices, but they are not what makes an item selectable.

Ordering strategy and day-to-day backlog management in more depth belong to the Product Backlog management lesson.

The Product Goal is the commitment of the Product Backlog: it describes a future state of the product that the Scrum Team can plan against. It is in the Product Backlog, and the rest of the Product Backlog emerges to define what will fulfill it. It is the Scrum Team's long-term objective, as opposed to the Sprint Goal, which covers one Sprint.

To make sense of "a future state of the product", the Guide defines a product: 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. The definition is about value and the people it serves, not about a project's scope, schedule or team structure.

The key rule: the Scrum Team must fulfill or abandon one objective before taking on the next. One product has one Product Goal at a time. That has two consequences that exams like to contrast:

• A product never has several Product Goals running in parallel; the team pursues one objective at a time.
• When a goal stops being worth reaching, the team does not have to finish it first. It can abandon the goal and take on the next one. Whether a Sprint should be cancelled is a separate question that turns on whether the Sprint Goal has become obsolete (see the lesson on the Scrum events).

Developing and explicitly communicating the Product Goal is part of the Product Owner's accountability.

The Sprint Backlog is made 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.

The Scrum Guide describes it as a highly visible, real-time picture of the work the Developers plan to accomplish during the Sprint to achieve the Sprint Goal. So it is updated throughout the Sprint as more is learned, not fixed at Sprint Planning, and it is not owned or edited by the Product Owner or approved by stakeholders. It needs enough detail for the Developers to inspect their progress in the Daily Scrum; that is the Guide's only test of "detailed enough"; the format and granularity of the plan are the Developers' choice.

If the work turns out different than expected, the Developers collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint, without affecting the Sprint Goal. The detailed rules for what may change during a Sprint are in the lesson on the Scrum events.

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

Its main job is coherence and focus: it encourages the Scrum Team to work together rather than on separate initiatives. Without one, a Sprint tends to fragment into individual initiatives that merely share a timebox. Of the three commitments, only the Sprint Goal states what one Sprint, taken as a whole, is for.

A Sprint Goal that simply restates the selected items is weak: it repeats the "what", so it offers no single objective and nothing to trade against when an item turns out larger than expected. A good Sprint Goal names an outcome, such as "let a returning customer reorder a previous basket in one step", so the Developers can renegotiate the exact items with the Product Owner while still achieving it.

Two near-misses to avoid: the Sprint Goal is not set by the Product Owner alone before Sprint Planning (the Product Owner proposes how the product could increase its value; the whole Scrum Team crafts the goal), and the Developers do not rewrite it mid-Sprint to fit what they managed. Scope can change; the goal is protected.

An Increment is a concrete stepping stone toward the Product Goal. The Scrum Guide gives it three properties:

• Additive. Each Increment adds to all prior Increments.
• Thoroughly verified, so that all Increments work together. Each Increment is verified together with everything built before it, not only on its own, so integration problems surface in the Sprint that caused them instead of accumulating for later.
• Usable. To provide value, an Increment must be usable. Usable means it could be used; whether and when to release it is a separate business decision.

An Increment is born the moment a Product Backlog item meets the Definition of Done. It is not created at Sprint Planning when items are selected, and it does not wait for the end of the Sprint or for the Product Owner to "accept" it at the Sprint Review; Product Owner acceptance is not a Scrum Guide step. Multiple Increments may be created within a Sprint, and an Increment may be delivered to stakeholders before the Sprint ends. The sum of the Increments is presented at the Sprint Review, which should never be treated as a gate to releasing value.

The flip side is strict: work cannot be considered part of an Increment unless it meets the Definition of Done. Any intermediate state short of Done, however close, does not make work part of an Increment.

The Definition of Done is the commitment of the Increment: a formal description of the state of the Increment when it meets the quality measures required for the product. It creates transparency by giving everyone a shared understanding of what work was completed as part of the Increment. It applies to every item that becomes part of the Increment, which sets it apart from anything specific to one item.

The Developers are required to conform to it. Conformance is the accountability of the Developers as a whole. Because the Definition of Done is a commitment rather than a guideline, the Guide offers no per-item exception: work that falls short of it is not Done, whatever the pressure to release it.

If a Product Backlog item does not meet the Definition of Done:

• it cannot be released,
• it cannot even be presented at the Sprint Review (not as "undone", not as "almost there"), and
• it returns to the Product Backlog for future consideration, where the Product Owner orders it with everything else.

From there it is treated like any other item: its position reflects its value relative to everything else, and it is worked on again only if Sprint Planning selects it from the ordered Product Backlog.

When time runs short, quality is not the variable; scope is. The Developers negotiate the scope of the Sprint Backlog with the Product Owner and keep the Definition of Done intact. Likewise, the Definition of Done must describe the real state of work that is called finished. If quality work still happens after an item is reported as Done, the definition is not telling the truth; the remedy is to bring that work inside the one shared definition, so "Done" means the same thing to everyone.

Where the Definition of Done comes from depends on the organization:

In practice, a team whose product needs more than the organizational standard demands builds its own definition on top of that standard. And when teams on one product differ about what Done should include, they resolve it together, because a shared Increment can only have one quality bar.

The Definition of Done is inspected at the Sprint Retrospective. There the Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done, and identifies improvements. When Increments fall short of the quality the product needs, such as defects reaching users after every release or failures in production, the Scrum response is to strengthen the Definition of Done itself, so that the quality bar every item must reach rises.

A stronger Definition of Done has knock-on effects. Items count as part of an Increment only once they meet the new criteria too, and the Developers must allow for the extra work when they select items in Sprint Planning; the Guide notes that knowing their Definition of Done makes their Sprint forecasts more confident. Once added, the new criteria apply to every item from then on, exactly like the rest of the definition.

Many popular practices are not in the Scrum Guide 2020, and PSM I distractors draw heavily on them. The safest habit is to ask "does the Guide say this?" before choosing.