Definition of Done

A “Definition of Done” describes what “done” means in an unambiguous way so that interacting individuals, teams or organizations can work together effectively.

Most organizations are made up of teams of teams and at each team boundary work requests and results are handed between teams at a certain level of completeness. Although close collaborative relationships, organically formed are often the most effective, this transactional behaviour is often necessary when teams have been organized to decompose large populations. Where transactional boundaries do exist, clarity over definitions of done, both in terms of incoming requests and quality of output is necessary.

One of the most common causes of conflict when teams need to work together is an inconsistent Definition of Done between the teams. Aligning on known definitions prevents conflict.

We recommend developing acceptance criteria associated with work requests, requirements and bugs/changes so that requests are fully rounded and results won’t be produced without the requisite level of quality. These levels of completeness and quality are “definitions of done”. In Holistic Software Development we explicitly define a stack of levels of done that correlate to the governance structures, decomposition of requirements, promotion through integration streams and loosely to levels of testing. Where possible we recommend testing to as high a level of done as possible to identify release candidates (or problems) as early as possible.

The defined set of levels we use are for guidance only, as with everything in the HSD you are welcome to tailor them to better reflect your organization. Definitions of done can range from a requirement being captured (not much value to an end customer but it could be “done” from a Business Analyst’s point of view) to being coded and unit tested (might be done from a development point of view but isn’t necessarily ready for integration and live deployment yet) to being fully live with support arrangements in place.

Because we focus on working software as the measure of progress in HSD the lowest level of done we recognize is “developed”. We recommend against definitions of done for intermediary artifacts or processes such as “written down”, “analyzed”, “designed” etc.
Whatever levels of done are used, and however they are defined, their critical purpose is to enable agreement between teams so communicating them clearly is more important than how many there are. Inconsistent or badly communicated Definitions of Done are a major source of cross-team conflicts, integration issues and quality problems.
People aren’t going to remember a stack of definitions of done, so we recommend putting them on an intranet, posters or mouse mats as a memory aid.

Levels of Done

The HSD defines a number of levels of Done as follows:

Developed – indicating the solution has been initally developed

Unit-Tested – indicates that the change has consistently passed its unit-tests (see Quality Confidence)

System Tested – indicates that the system has consistently passed its system requirements and acceptance criteria as represented by the Product Backlog

Integration Tested – indicates that the product has been successfully integrated and that Integration Scenarios across multiple team Product Backlogs have been proven

Product User Acceptance – indicates that user acceptance criteria has been met and that users have formally accepted the product.

Product Family Integration Tested – indicates that a family of related products has been successfully integrated and Integration Scenarios across Products have been proven, integration acceptance criteria have been met

Product Family User Acceptance – indicates that a family of related products has met its user acceptance criteria and that users have formally accepted the product

End 2 End Tested – indicates that business benefit scenarios have been proven and that the larger business system delivers value. This level serves as acceptance criteria for Portfolio Requests.

Business Acceptance – indicates that the business has formally accepted the product and that support and maintenance arrangements are in place. At this point the solution should be at least part way towards meeting a Strategic Goal.

We do not recommend a simple linear progression of systems through these levels of done. Instead, we recommend testing each requirement against as high a level as possible as often as possible (within cost/resource constraints). Collectively a component, product or product family can be promoted though the levels based on progression of its constituent requirements. For new developments as we move up the levels we tend to look at larger whole systems rather than single requirements. Alternatively, for maintenance of established products, or continuous flow against stable products, single requirements/changes may progress through the levels.

Use of Levels of Done

Software Engineering practices exist to move requirements, products and product families through the levels of done. For this reason the Definitions of Done are referred to throughout Holistic Software Development, especially in terms of:


A Milestone is a significant event or decision point in the lifetime of a project.

Holistic Software Development uses a standard set of layered Milestones to drive the Risk-Driven Lifecycle. Milestones are a useful way of tracking top-level guesses about when scope will be delivered. Like estimates, they should not be treated as deadlines.


Requirement is a condition or capability that must be met by a system or component to satisfy a contract, standard, specification, or other form of request.

Integration Streams

Integration Streams combine the output of multiple developers, and/or from multiple contributing teams in a complicated or complex system. They also provide a staging mechanism for testing prior to promotion from “build” to “release” enabling progression through the levels of done. Integration Streams are typically implemented as “streams” or “branches” in version control tooling.

Builds and Releases

A Build is change or collection of changes, integrated into a product, that has had some (typically minimal) level of inspection and quality assurance.

A Build may be performed at an individual personal level or at a team level where changes from more than one team member are integrated into the build. Inspection and quality assurance activities are normally a little more involved at team level as the Definition of Done is a little higher but builds do tend to have a relatively low Definition of Done – not every build will be fully tested. Builds happen frequently, often many times a day.

A Release has a dual nature:

A Release is typically formed once in a Release planning timebox after a succession of internal builds but can be created from every successful team build when Continuous Deployment practices are used. Releases will reach a high Definition of Done, often as far as “End 2 End Tested” but may not necessarily be adopted by the business just because they are ready as Adoption and Business Change cycles may be decoupled from Release cadences.


Quality is meeting the true end goals of the customer. Quality indicates how well, from a Customer’s perspective, a product meets its functional and non-functional requirements – without problems. Quality is an indirect measure of how much business value a product delivers but a direct measure of the relationship between users and a product.