The value stream

The Definition of Done and quality

"It's finished" is one of the most ambiguous sentences in teamwork. The Definition of Done settles in advance what the word means for everyone. A Scrum Book surrounds it with four other patterns: keeping the product in order every day, fixing defects as soon as they appear, producing a usable Increment every Sprint and, in some cases, delivering it without waiting for the end of the Sprint.

"It's finished, there's just…"

A team is developing invoicing software for a network of accounting firms. During the Sprint Review, a developer shows the new invoice export feature.

"Will the firms be able to use it on Monday?" asks the Product Owner.

"The feature is finished," the developer replies. "We still have the tests on large files and the release to production."

"And the help page?"

"It isn't written, but that wasn't part of my task."

"So when is it finished?"

The Definition of Done pattern opens on a very similar scene. The same word takes three meanings: the code is written, the work has been checked, the customer can use it. As long as these meanings coexist, the Product Owner cannot promise anything to anyone.

Definition of Done: a single meaning for "finished"

The Definition of Done pattern (which the book also nicknames Done-Done) states the problem this way: each team member may have their own idea of what finished work is. Yet the Product Owner needs to know the real state of the product to decide what comes next. For one developer, "done" implies documentation, a review and no known defects, while for the person at the next desk it is enough that nothing breaks in a quick trial. Quality therefore varies from one item to another. When it falls short of expectations, time would be needed to stabilize the product, but the Sprint is over, and the delays create tension within the team.

One last force is less visible. It is easy to say nothing about a convention that was not followed or a check that was skipped. The team then takes on technical debt: it owes the product work that will have to be done later. This debt appears in no backlog and cannot be seen at the Sprint Review, which only shows the outside of the product.

The solution is for all the Scrum Team's work to meet a list of criteria agreed between the Developers and the Product Owner. An item is Done when the Developers have checked that no known work remains with respect to these criteria. Otherwise it is not Done and cannot be delivered. The book adds several points.

• The ideal definition covers everything needed to put the product in the customer's hands. A team starts from what it can genuinely achieve today and strengthens its definition over time, for example at the Sprint Retrospective.
• Each criterion is objective and verifiable. The child who answers "yes" to "have you tidied your room?" answers "no" when asked whether the toys are put away and the bed is made. A criterion therefore describes an observable state rather than an activity, which makes it possible to present the definition as a checklist.
• The definition takes in the small repetitive tasks that would clutter the Product Backlog, such as updating a technical document or cleaning up the workstation.
• A criterion that brings value to no stakeholder is waste.
• Several teams working on the same product share the same definition. The book does accept, however, that one team may keep separate definitions for different kinds of work (documentation, calculations, code) when a single list covers them poorly.

The authors expect from it more reliable forecasts, since what has been declared finished does not come back, and the disappearance of "stabilization Sprints" devoted to catching up on quality.

Good Housekeeping: not leaving the mess for tomorrow

The Good Housekeeping pattern (also called Daily Clean Code) states its problem simply: where there is a mess, time and energy are lost working out where to start. Anyone who has to clean up before working, or redo a task because they did not know the state of the work, wastes their time. Putting off the tidying until the end of the Sprint solves nothing, because that end is always taken up by work deemed more urgent.

The solution is to keep the product and the working environment in a clean state at all times, or to bring them back to it at the end of each day. Every evening the product must be in a state that meets the criteria of the Definition of Done, even if it is not yet an Increment, so that any team member can safely pick up the work the next day. In a software team, this means for example that the evening's code builds and passes its tests.

The authors warn against the opposite excess: an empty desk hides the state of the work as much as a cluttered one. They link the pattern to the 5S (in French) of the Toyota Production System and to the scouts' rule of leaving the campsite cleaner than you found it. If daily tidying seems too costly, they see it as a sign of a tool that is too slow or of a design flaw, to be treated as an impediment.

Whack the Mole: fix it straight away

The name of the Whack the Mole pattern comes from the carnival game in which you hit, with a mallet, the moles that pop out of their holes. It deals with the tension between moving the product's features forward and raising its quality. Under commercial pressure, defects look like distractions, and fixing them gets postponed. The authors set several arguments against this postponement. According to Steve McConnell (1996), defects slow down the whole of development by forcing workarounds. A defect costs less to fix while its context is still fresh. A defect list kept on the side is an inventory that prevents the whole of the work from being ordered, and a "clean-up Sprint" leaves the product defective until its date comes around.

The book reports the story of a client who found 2,000 top-severity defects in its tracking tool and launched a Sprint to cut their number by 60%. The teams met the goal by moving about 60% of these defects down to the lower severity category.

The solution is to resolve the product's problems as soon as they appear, small or large, without creating an item in the Product Backlog. Repairing a product that works badly comes before enhancing it. One or two developers take it on while the others carry on, and they make this work visible on the board and at the Daily Scrum. They devote to it a maximum time agreed in advance, the book giving four hours as an example. Once that time is up, the Product Owner decides whether to continue, at the risk of not finishing a planned item, or to put the problem on the Product Backlog. The fix itself meets the Definition of Done. As for the process that let the defect through, it is usually corrected later, at the Sprint Retrospective.

Regular Product Increment: something usable every Sprint

The Regular Product Increment pattern responds to a difficulty for the Product Owner: how can you be sure, Sprint after Sprint, that the product is really gaining value? Abstract indicators, such as the "earned value" of project management, measure progress detached from the product itself. Specialists from different departments may each have finished their part without the whole working, whereas the value comes from putting it together.

The solution is for the Scrum Team to strive to deliver every Sprint a Done Increment, usable and ready to be put into service. This Increment is used to check whether the product's value has increased and to observe how it behaves with its users. Reporting then becomes simpler, since an item is either Done or it is not.

Responsive Deployment: delivering without waiting for the end of the Sprint

The Responsive Deployment pattern looks at a limit of the Sprint rhythm. An item finished on the third day waits for the end of the Sprint in what the authors call inventory. It will take one more Sprint to learn how it is received and a third to react. A defect fix waits in the same way, while users go on suffering from it. In the other direction, grouping deliveries reduces their administrative cost.

The solution is to put certain items into service as soon as they are Done and the Product Owner approves them, during the Sprint itself, provided the cost of these scattered deliveries does not exceed their benefit. A short review accompanies each partial delivery, and the substantive questions are kept for the Sprint Review.

The authors have reservations about their own pattern. They intend it for mature, disciplined teams, above all for defect fixes, emergencies and serving a single customer who is close at hand, because nothing annoys users more than seeing their tool change all the time.

What the 2020 Scrum Guide says

• The Guide makes the Definition of Done the commitment attached to the Increment: a formal description of the state of the Increment when it meets the quality measures required for the product.
• If a definition exists as part of the organization's standards, all Scrum Teams follow it as a minimum. Otherwise the Scrum Team creates its own. The 2017 edition gave this task to the Development Team, and the book describes it as an agreement between the Developers and the Product Owner.
• An item that does not meet the definition can be neither released nor even presented at the Sprint Review. It goes back to the Product Backlog. The 2020 Guide does not speak of the Product Owner "accepting" items, whereas the book has the Product Owner approve each one.
• The book speaks of a "potentially shippable" Increment, as the 2017 Guide did. The 2020 Guide says only that the Increment must be usable. It specifies that several Increments may be created within a Sprint, that an Increment may be delivered before the end of the Sprint and that the Sprint Review should never be considered a gate to releasing value. What the book reserves for experienced teams is therefore explicitly allowed by the Guide.
• The Guide makes the Developers accountable for instilling quality by adhering to the Definition of Done. In the book, the Scrum Master watches over this by making visible any unfinished work that is about to be delivered.

Limits and pitfalls

A Definition of Done can fail in two ways. Too weak, it declares finished work that nobody can use. Too ambitious for the team's means, it is never met, and people get into the habit of getting around it.

The Definition of Done is often confused with the acceptance criteria specific to one item. The first applies to all the team's work. The second describe what a particular item must do and belong to the specification, covered in the article on refining the Product Backlog. An item must satisfy both.

Immediate fixing has its own risks. It can swallow the whole Sprint: the authors then see it as the symptom of a serious quality problem, which justifies the emergency procedure. And it does not reduce technical debt already accumulated.

More broadly, the idea that a strict definition does away with stabilization Sprints and keeps technical debt in check rests on the authors' experience. It is plausible and consistent, but the book offers no comparative study to back it. The corpus's critical article takes stock of what research allows us to say.