Simplicity and Complexity

Simplicity and Complexity

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 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 provides 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 unit 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 functionality components, however functionality is generally included in the definition through satisfaction or acceptance criteria.  In some cases I have seen a statement in the Definition of Done indicating that the acceptance criteria must be met. 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 requires weighing the answers to a number of definitional questions that complicate what is otherwise a fairly simple process.  The questions that must be answered include:

  1. 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 the 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.
  2. 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. The answer is often yes. Getting to yes generally involves a discussion of the gray area, accepting technical debt and then committing to when the debt will be retired.
  3. 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.