(If you need to create your own Definition of Done, we’ve written a guide for that too.)
What Problem Does the Definition of Done Solve?
In Scrum, the goal of each Sprint is to build a complete product Increment and release it to the customers and end users. This suggests that Scrum defines done as “in use” by the customers and end users. Done does not mean handing-off the Increment to another team or allowing the Increment to wait in some queue for integration later.
Done is an essential concept in Scrum because it promotes visibility regarding the true state of the product Increment through the inspection of a usable product at the Sprint Review. If you recall, visibility is one of the three pillars of empiricism and is crucial to allow a healthy Scrum Team to inspect and adapt. Done also reveals the Scrum Team’s ability, or lack of ability, to produce the product Increment within the constraints provided by the organization. Anything which prevents the Scrum Team from reaching Done is considered an organizational impediment that must be eliminated. If the Scrum Team cannot reach Done, then the stakeholders need to be aware of this and take action to remedy the situation.
However, because Done can mean many different things to various people, depending on their role and perspective in the organization, the Scrum Team and stakeholders need clarity on what is being inspected at the Sprint Review — enter the Definition of Done.
Definition of Done Defined
The DoD is a cross-functional and concise list of technical criteria — from six to twelve items — that each Product Backlog item must meet in order to be considered usable by a new, or existing, customer. The DoD defines the commitment the Developers make to preserve and enhance the intrinsic quality of the product Increment. At a minimum, the DoD for a software-powered product normally includes design, analysis, coding, testing and some form of documentation.
The DoD applies uniformly to all the items in the Product Backlog and may not be sacrificed in response to time pressure. This is a very important concept to bear in mind when adopting Scrum. It’s so important the Scrum Guide places the following two restrictions on the Scrum Team and organization related to the DoD:
- Product Backlog items which do not meet the DoD are not allowed to be released to customers or end users. This restriction encourages the Scrum Team to refrain from releasing a substandard version of the product to the customers and end users. One way to visualize the product Increment is to think of the it as a meal, and the DoD are the ingredients. Ideally, the product would be nutritious and tasty because the DoD has high quality ingredients. If you would not feed your product to your dog, then it does not deserve to be served up to the customers and end users (i.e., no Squirrel Burgers).
- When Product Backlog items do not meet the DoD, they cannot be demonstrated at the Sprint Review. If these Product Backlog items are shown at the Sprint Review, it gives the stakeholders a false sense of progress. It also condones the idea that Scrum Teams can cut corners on quality in order to achieve their goals. While these items may not be demonstrated at the Sprint Review, instead the Scrum Team must make these items visible to the stakeholders. This is to ensure these impediments are revealed and addressed by the stakeholders.
Finally, the DoD is owned collectively by the Developers and they are required to follow the DoD at all times. When multiple Scrum Teams work on the same product simultaneously, they are required to have a single DoD which applies uniformly to all Scrum Teams working on that product.
Confusing DoD with Acceptance Criteria
A common error is to confuse Acceptance Criteria (AC) with the DoD. Here are three reasons why the DoD is NOT the AC:
- AC describe how the customer, or end user, would validate that the value contained in the Product Backlog item has been delivered to them. The DoD describes how the business would validate the quality of the product.
- AC are specific to a single Product Backlog item and are owned by the Product Owner. The DoD applies to every item in the Product Backlog and is owned by the Developers.
- AC define how well the product Increment meets the needs of the customers and end users (i.e., the extrinsic quality of the product). The DoD is a definition describing the engineering standards used to build the product, i.e., the intrinsic quality of the product.
Another error people often make is to include the AC as part of the DoD. In effect, requiring the customer’s needs to be satisfied as a precursor to releasing the product Increment. This is a noble objective but it has some drawbacks:
- It is superfluous. Another way to look at the DoD is as a series of behaviors the Developers want to install as professional habits: test-driven development, automated integration tests, code reviews, etc. If the Developers need to explicitly establish – “satisfy the needs of the customers and end users” – as a habit, then the Scrum Team has a bigger problem that can be resolved with a DoD.
- Slows forward progress. In Scrum, the first responsibility of the Developers is to develop a high-quality product Increment which conforms to the DoD. At this point, let us assume the Developers have built a product which meets the AC as originally defined by the Product Owner. However, we all know that customers and end users are fickle. After interacting with the Increment, the customers could decide their needs have not been met. So what does the Scrum Team do? If meeting the AC is part of the DoD, the Scrum Team is clearly not done. This could result in the Scrum Team being trapped in a never ending cycle of incomplete Product Backlog items based on the shifting whims and desires of the customer. That is not a good place to be in, especially if the Scrum Team is expected to deliver against a deadline. If meeting the AC is not considered part of the DoD we can change the dynamic. If we encounter the aforementioned scenario, everyone would agree the Product Backlog item is done, i.e., the Developers have provided a high-quality product Increment, but the customer has now offered a change. That change may, or may not, be added to the Product Backlog depending on the upcoming Sprint Goal(s) and the overarching Product Goal. By separating intrinsic quality, engineering quality, from extrinsic quality, customer satisfaction, this enables the Scrum Team to make regular forward progress.
- Muddies the water between who owns intrinsic vs. extrinsic quality. By including the AC in the DoD, this gives customers, end users and stakeholders the impression they have a voice in defining technical quality. Specifically, I am concerned these parties would tinker with reducing technical quality as the means to achieve their goals. However, this quote from the Scrum Guide – “if a Product Backlog item does not meet the Definition of Done, it cannot be released” – suggests customers, end users and stakeholders are not allowed to tinker with technical quality. In Scrum, intrinsic quality is meant to remain high, undisturbed during the course of a Sprint and owned by the Developers. Of course, if customers, end users and stakeholders want the Developers to increase intrinsic quality, the Scrum Team will need to find ways to accommodate this desire.
That is the crucial information you need to know about the DoD. Next up, I will offer you a simple framework for building your own DoD.