Scrum Explicit Contracts: The Definition of Done

In my experience as an Agile Coach, I have observed that Scrum teams often have some challenges defining the team's Definition of Done (DoD).

The Definition of Done is an agreed-upon set of conditions; an explicit contract that must be met before any product backlog item is considered complete. Some examples of these conditions are:

• The code has passed identified tests with no Severity One or Two defects
• The code is tested in an appropriate test environment
• The code is checked into the code repository
• The code has been inspected and reviewed as dictated by the organizational engineering practices
• The code is compliant with required organizational software engineering governance (unit tests, code documentation, etc.)

The DoD may be influenced by environmental factors as well as organizational factors. For example, the test environment the team has access to during a sprint can affect the depth and breadth of testing that can be completed on a user story. While the available test environment may allow the team to validate the functionality of a user story, the test environment may not allow sufficient interaction with other production-like systems to determine if the user story is a "shippable" product increment.

Many times, the team must make the decision with guidance provided by the organizational engineering policies when defining the DoD if the functionality of the user story can be validated without "production interface" testing. Often, test data sets and mock data can be used to validate user stories and simulate interaction with production systems so that user stories may be completed in accordance with the criteria specified in the Definition of Done.

The Definition of Done needs to define the minimum work required to get a product increment (user story) to the "done" state. Individual features or user stories may have specific "done" criteria in addition to the ones that apply to user stories in general. Examples of additional criteria might be performance requirements for query responses used to support application screens. These additional "done" criteria may manifest themselves as "acceptance conditions" for individual user stories.

Obsessing over the Definition of Done and the associated list of criteria can be counterproductive. In fact, overly scrutinizing or being too stringent with the Definition of Done can be detrimental to the Team's progress and velocity because unrealistic conditions of acceptance cause the team to put energy and effort into activities that may not be achievable during the sprint.

After the team agrees on the Definition of Done, the definition should be prominently displayed in the team room. When the DoD is merely a shared understanding, rather than being spelled out and displayed on a wall, it often loses much of its effectiveness. A lot of the value of a "formal" Definition of Done lies in the fact that this definition is an explicit contract known to, and agreed upon, by all members of the team.

The team actually uses the Definition of Done at the end of a sprint to justify the decision to demonstrate functional user stories and credit work towards the team velocity. The team should all agree that failure to meet the criteria identified in the Definition of Done at the end of a sprint means that the user story (product increment) should not be considered "done" and therefore any story points associated with the user story will not be counted toward the team's sprint velocity.