Definition of Done: Why "Done" Rarely Means Done in a Company

The definition of done describes which quality measures a work result must meet before it counts as done. The 2020 Scrum Guide makes it a binding commitment for the developers. In a company, problems usually arise where development, operations and the business unit each understand something different by done. This article offers a checklist, a level model from code to benefit and the steps for anchoring the definition in the organisation.

A team reports an order as complete, the business department finds it unusable, operations has never heard of it, and three weeks later rework appears on the list. The sequence is so familiar in many organisations that it passes for a normal part of delivery. Its cause usually lies in an unspoken assumption: each group measures completion by the part it sees itself. The definition of done fixes this yardstick in writing.

What is the definition of done?

The definition of done is a formal description of the state an increment must reach when it meets the quality measures required for the product. This is how the Scrum Guide by Ken Schwaber and Jeff Sutherland puts it in the version of November 2020. An increment comes into being at the moment a Product Backlog item meets the definition. If it does not, it can neither be released nor shown in the Sprint Review, and it returns to the Product Backlog.

The Scrum Guide also states that where an organisation has a company-wide definition, it applies as the minimum standard to all Scrum Teams. Where no such rule exists, the Scrum Team develops a suitable definition for its product. The developers are required to conform to it. That sets it apart from a recommendation: the definition is a quality agreement between the team and itself and with the organisation.

The definition of done is to be distinguished from acceptance criteria. Acceptance criteria apply to each item and describe what that item must deliver in business terms. The definition of done applies to all items alike and describes the quality every result must have. A definition of ready, often named as a counterpart, is not in the Scrum Guide and is not part of the method.

Why does “done” so rarely mean done in a company?

“Done” so rarely means done in a company because several parties work on the same result and each sees a different end point. For development, the work ends with tested code. Operations additionally needs monitoring and an operations manual as well as clear ownership of incidents. The business unit needs a trained workforce and adapted processes as well as access to data. Senior management, for its part, expects a metric that moves. Each of these views is legitimate, and none alone makes a finished result.

The consequences can be measured. Anyone who measures completion by code books effort as done that returns later as rework. Ward Cunningham described in 1992, with the image of technical debt, how shortened completion later costs interest. The work of Sculley and colleagues from 2015 shows for machine-learning systems that the learning code makes up only a small part of the whole system, while data maintenance and configuration as well as monitoring make up the larger part. A result that counts as done without these parts is not done.

A calculation makes the effect visible. In one quarter a team reports 20 orders as done. For six of them operations demands rework, and for two more the training of users is missing. The effective completion rate is 12 out of 20, or 60 per cent. The figure is an illustrative worked example, but it shows the principle: every piece of rework takes away capacity that is then missing for new orders, and so lengthens the lead time of all orders. How lead times fall when work in progress is limited is described in the article Introducing Kanban: managing flow instead of utilisation.

Which five done levels run from code to benefit?

Five done levels show how far a result really is and give every group a shared yardstick. They build on one another, and a result counts as done only when it reaches the level the company sets as its minimum standard.

The Scrum Guide requires a usable increment for the definition of done. If operations belongs to the product, that includes levels 1 to 4. Level 5 lies after release and is therefore a goal of the Product Owner and no part of the definition. In practice it is advisable to make level 4 binding and to take level 5 into the Sprint Review as a metric.

What does a definition of done checklist look like?

A definition of done checklist covers criteria in four groups, which a team adapts to its product. It stays short so that it is actually checked for every item, and it rarely exceeds ten points.

The list is drawn up jointly with all parties involved, above all operations and the business unit. It is reviewed and adjusted in the Sprint Retrospective as soon as a defect shows that a criterion is missing. Whoever finds a gap adds to the list and passes the hint to the other teams.

How do you anchor the definition of done in the organisation?

You anchor the definition of done in four steps, which team and management take together.

1. Establish the starting point: the organisation examines the last ten results reported as done, looking at how often rework arose and why. This yields the criteria that have been missing.
2. Set a minimum standard: senior management agrees with development, operations and the business unit on a company-wide core that all teams meet. Teams add their own points for their product.
3. Make it visible: the definition hangs at the board and belongs to the flow of every item. An item that does not meet it does not move to the done column and does not count in the statistics.
4. Measure the effect: effective completion rate, rework per order and time to use show whether the definition works. The values go into the retrospective.

The hardest part lies in leadership. A definition of done works only if managers accept that a result returns when it fails the definition, even when a deadline presses. If the definition is relaxed under time pressure, the organisation silently adopts a second, lower version, and rework grows. Shaping teams by flow and ownership makes this easier, because a team with end-to-end ownership has reason to keep the definition. The article Team Topologies: organising teams around the flow of work describes this shape. Experience with Scrum after the first year is in the article Scrum in mid-sized companies.

Definition of done with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the field of delivery management he works as delivery manager, project manager or product owner and ensures that development, operations and the business unit understand the same thing by done.

The approach follows the Niehues Delivery Model. Three test questions matter for the definition of done: who decides, who delivers, who uses? Who is accountable for operation from day one? Which metric shows after 90 days that the solution has taken hold? The scope and terms of an engagement are discussed in the free initial consultation, which you can arrange through the contact page.