How Should You handle Definition of Done?

2018-10-02

Definition of Done

Scrum and LeSS have a stringent discussion concerning Definition of Done. The key question is

Considering our current context and capability, what activities can be completed in each sprint?

This subset is the initial Definition of Done.

A Definition of Done is weak when it is a small subset and strong when it almost equals Potentially Shippable.

In huge organizations, the development teams discuss their context and select the subset of the activities that all teams think they realistically can do during the sprint. This is their initial Definition of Done. The teams that can do more will expand this product Definition of Done within their members.

The difference between the Definition of Done and Potentially Shippable is referred to as Undone Work.

Potentially Shippable - Definition of Done = Undone Work

The Sprint is planned according to the Definition of Done and thus the Undone Work is excluded. It is planned to be left undone.

The terms Potentially Shippable and Definition of Done are often not used consistently. To clarify the terms:

Potentially Shippable	All activities that must be performed before the product can be shipped.
Definition of Done	An agreement between the teams and their Product Owner on which activities are performed inside the Sprint. A Definition of Done is perfect when it equals Potentially Shippable. Teams strive to improve towards an ideal Definition of Done.
Undone Work	The difference between the Definition of Done and Potentially Shippable. When the Definition of Done is perfect, then there is no Undone Work. If this is not the case, the organization has to decide. First, how we deal with the Undone Work. Second, how we improve so that there is less Undone Work in the future.
Unfinished, or not done—work	that was planned in a sprint but was not completed. This is often confused with Undone Work.
Unfinished	is work that the team planned for but did not finish, whereas Undone Work was never even planned for? When a team has work that was not finished, then they ought to feel anxious and discuss improvement actions during their retrospective.

Teams should never leave work-in-progress at the end of the sprint and carry over to the next one. This causes a lack of transparency and reduces flexibility. The product owner has more trouble to change the scope of the application. If they forecast too much work, they need to remove completed items, which they have not started yet.

Scrum Guide Definition

The Scrum guide characterizes the Definition of Done as follows:

The Definition of Done is a formal description of the state for the Increment when it meets the quality measures required for the product.
The moment a Product Backlog Item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog Item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

Items of a Definition of Done

A delivery standard as defined by the team.
It contains all requirements to get a user story into production.
The fitness for use is evident (enough value was built to justify releasing?).
The external quality is verified (we have built the right thing?).
The internal quality is verified, you wrote unit tests – and all tests are green.
The code is checked in. The branch was merged and deleted.
Coding standards are enforced through static check tools and integrated in the continuous delivery pipeline.
The code review was completed.
All improvements from the code review were implemented.
All existing unit tests remain green.
The acceptance tests were verified by the development team.
All integration tests were passed.
And the Status of done was confirmed by the product owner.

The following criteria are often overlooked and also need to be checked:

Was the technical documentation updated?
Was the user documentation updated?
Was the user documentation localized?
The localization for the application is done.
The localization testing is done.
The marketing input is done.
The legal documents are done.
The deployment and migration scripts are available.

The extension of the definition of done DoD to deliver a potentially shippable product has often significant and profound impact on the structure of the organization and its processes. Experienced agile coaches use the definition of done as an instrument for organizational changes.

When the undone work is slowly removed from the delivery process, it triggers structural and process changes. For example, the separate quality department responsible for the final tests is dissolved and their expertise is integrated in the development teams.

See also the blog Pragmatic Craftsmanship for a discussion of built-in quality.