A Simple Life!
The Definition of Done is an important Agile technique to help teams plan and execute work. The simplest definition of the Definition of Done is the criteria that a work product must meet to be considered to be complete. While the concept is simple, the implementation of the technique in the real world is rarely simple. Both context and interpretations make things just a bit gray!
The first layer of complexity is that the Definition of Done must be understood in the context of an environment that must account for technical completeness, functional completeness, and the product owner’s acceptance. The product owner’s acceptance of the product can be considered as a proxy for value. Acceptance criteria or satisfaction conditions, regardless of what they are called, are a reflection of whether the code solves the specific business problem defined by the user story or requirement. Acceptance criteria are used to confirm that the story does what was intended and can be used to create an acceptance test.
Technically, the Definition of Done is often a reflection of organizational technical and process standards. For example, organizations often have coding and testing standards so the criteria for the Definition of Done might include the requirements for the code structure, documentation, and testing. The Definition of Done may also include functional components, however, functionality is generally included in the definition through the satisfaction of acceptance criteria. In some cases, I have seen a statement in the Definition of Done indicating that the acceptance criteria must be met (which is somewhat circular). Finally, the product owner’s evaluation of the value delivered by the solution after meeting the twin hurdles of done and acceptance sets up a final evaluation in which the product owner accepts or rejects the solution. I have heard the outcome of this process described as done-done or even done-done-done.
Implementing a concept of done in a robust manner includes three hurdles; the criteria in the Definition of Done, acceptance criteria (part of a User Story) and the product owner’s acceptance. Implementations also require weighing the answers to a number of definitional questions that complicate what is a fairly simple process. The questions that must be answered include:
Who decides what done means technically? In many organizations, the criteria that define done are often left to the discretion of individual teams. That discretion typically operates within the limits defined by the organization’s technical and process standards. For example, a few years ago I was asked by a development team, in an organization with stringent coding and unit testing standards, whether they could remove unit test requirements for their code. Unit testing was one of the criteria in their Definition of Done. Their rationale was that testers would find out if it worked later in the process and their product owner did not like the coders’ testing. However, the team only had discretion within the boundaries defined by organizational standards. In this case, the organization defined one of the requirements for what done meant from a technical perspective, and it wasn’t an option to remove the unit test requirements.
Can it be acceptable for all of the criteria in done be incomplete? Every team I have ever been involved with has sooner or later had to face the question of whether it is ever ok to shortchange the Definition of Done. Even though the answer is often yes there are bright lines that should be avoided. For example, waiving the need (for whatever reason) to test a solution and assuming it will work is a bridge too far. If a change is so mundane that you can’t see the need to test then testing should be simple therefore avoid the risk, if something appears untestable then you need to find a way to test and avoid the unknown risk of failure! In the more mundane scenarios, getting to yes generally involves a discussion of the gray area, accepting some technical debt and then committing to when the debt will be retired.
Can the organization’s needs outweigh the needs of a product owner? This is the alter ego of the previous question. Everyone on the team, including the product owner, needs to understand when and where organizational standards and/or needs will trump a product owner’s acceptance. Pressure to deliver can often incent a team and product owner to push code forward with the intention of refactoring in later sprints which pushes the envelope of standards and architecture. Most mature organizations establish bright lines so that everyone knows where organizational needs and standards must be respected.
All definitions of the word done connote a degree of finality; of being complete. In software development, enhancement, and maintenance environments, the concept of done can have many layers. Each layer
can have different technical, functional, and value-oriented nuances. Teams quickly learn that to be truly done, a piece of work must really be done, done and done.