How Should You handle Definition of Done?

An agile team is sole responsible for the internal quality of the product they build and maintain.

And the developers shall be accountable to produce the expected quality and optimize long terms goals of the organization.

They provide the answer to the seminal question

Did we build it right?

Definition of Done DoD is a major building block to answer this question with a sounding yes.

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 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 is almost equals to Potentially Shippable.

In huger 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 to Potentially Shippable. Teams strive to improve towards a 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 isn’t the case then the organization has to decide, first how do we deal with the Undone Work, and second how do we improve so that there is less Undone Work in the future.

Unfinished, not finished, or not done—Work that was planned in a Sprint but wasn’t completed. This is often confused with Undone Work. ‘Unfinished’ is work that the team planned for but didn’t 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 scope flexibility. If they forecast too much work, they need to remove complete items which they haven’t started yet.

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, if necessary the branch was closed and deleted,
• 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 definition of done 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 build-in quality.