Definition of done (DoD) is one of the most important practices that ensures release quality and allows the teams to align around what quality is and how it is built into the solution. It enables delivery of increments useful to the customer at the end of each iteration, program increment (PI), Solution increment or Release, and ensures non-functional requirements are handled well. In SAFe® (Scaled Agile Framework®), it represents one of five primary dimensions of Built-in quality that along with Alignment, Transparency and Program Execution form SAFe’s four core values.
What is Definition of Done?
Definition of Done is an agreed-upon set of items that must be completed before a project or user story can be considered complete. To put it short, it is a checklist of practices that help ensure transparency, clear responsibility, as everybody knows what to do and what the expectations are, timely delivery of necessary work, more accurate estimates and, of course, higher quality. The DoD checklist should be created by the team and agreed upon in the working agreement sessions. It is then used at the end of each increment, and it helps set clarity across all the teams and management about completion of iteration, PI, Solution increment or Release.
Although very important, DoD is believed to be one of the most misunderstood practices and is often being ignored. Some teams go even further and mix it with acceptance criteria. To clarify, DoD includes necessary, value-added activities that assert the quality of a feature and not the functionality of the feature, unlike the acceptance criteria. Further, DoD is always defined upfront, before development begins, and it applies to all user-stories/features within an increment, whereas acceptance criteria is specific to a particular piece of work (feature) and can be defined much later in the process. In some cases, even just before the start or during development.
Impact can be devastating
Inability to reach an agreement on DoD, avoiding it or it not being well-defined, can lead to a gap between teams and management about the done, it can severely endanger completeness of Iteration, PI, Solution Increment or Release and cause customer dissatisfaction. On top of that, it can lead to Non-Functional Requirements (NFRs) to be missed out, cause increase of production defects and delays as some of the increment items may require rework.
To avoid such scenarios, it is recommended that the first cut of the DoD checklist is created by Coaches, or Release Train Engineers (RTEs). The list should then be socialized with teams and management, reviewed, adjusted based on their inputs, and agreed on.
Examples of Definition of Done
DoD checklist should contain Functional and Non-Functional Requirements, that illustrate the completeness of the iteration or PI increment or Solution increment or Release. Examples of practices, are:
- Require work to be peer-reviewed
- Show all quality tests passed successfully (ideally automated)
- Ensure that all associated files have been checked-in and delivered
- Ensure all versions have been generated and published
- Check that email notifications have been sent
The DoD should be brought up at the end of the iteration, once stories are accepted by the product owners, or at the end of the PI increment, once Features are accepted by the product managers. All the items should then be checked if they are completed to close the iteration or PI.
SAFe’s scalable Definition of Done
DoD can be applied at any level – team, program, large solution, portfolio or enterprise, and to different items, such as User Stories, Features, Capabilities, Epics, Iterations, Releases and Program Increments. DoD must be visible to the team members at all times and used when items are moved to from one step to the other – and especially when they are moved to ‘done’.
As the SAFe Framework as a whole, the DoD is scalable too. In scaled DoD each higher-level definition assumes all the criteria of the lower levels plus adds new criteria.
Scalable Definition of Done Definition of Done is an important way of ensuring increment of value can be considered complete. The continuous development of incremental system functionality requires a scaled definition of done to ensure the right work is done at the right time, some early and some only for release. An example is shown below, but each team, train, and enterprise should build their own definition. While these may be different for each ART or team, they usually share a core set of items (@ScaledAgile, Inc.).
