The Subtle Differences Between Definition of Done and Acceptance Criteria

No topic causes more confusion for new, or experienced, Scrum practitioners than the Definition of Done (DoD).  To help reduce this confusion, let’s explore what it means to be “usable,” why “in use” is so important for change and how the DoD is different from acceptance criteria.

Usable Defined

In Scrum, cross-functional teams commit to deliver a “valuable, useful Increment every Sprint”.  Within the context of a team using Scrum to build software, usable means that the product is “in use” in its intended environment by its intended audience.  

So what does “in use” mean?  For teams that use Scrum to build software, “in use” means the software has been migrated to the customer’s (or end user’s) environment and people are receiving value from the software.  “In use” does not mean that the software has been handed-off to another team.  “In use” does not mean the software is waiting in some other queue for future integration.  

Why is “In Use” Important?

The requirement to create usable software that is “in use” by the time the Sprint timebox expires is one of those subtle concepts in Scrum that is easy to overlook, but is very important.  When the Scrum Team has “in use” as their objective, this fosters greater transparency regarding the state of the Increment.  If the Increment has not been put “in use” by the time the timebox expires, it’s not considered done.  

For teams and organizations that want to use Scrum to drive change, “in use” is a very powerful lever to create change.  Why?  Because it demonstrates to the stakeholders if the Scrum Team can deliver the software within the constraints they define.  Anything which hinders the Scrum Team’s ability to put the Increment “in use” must be documented as an impediment, requiring resolution by the Scrum Team or the broader organization.  Without “in use”, organizations have little motivation to make the necessary investments to disrupt the status quo. 

DoD Defined

The DOD is a commitment associated with the Increment.  Specifically, it “is a formal description of the state of the Increment when it meets the quality measures required for the product.”  The DoD documents the commitment the Developers have made to maintain and improve the intrinsic quality of the Increment. 

For a team using Scrum to build software, the DoD is a concise checklist of the technical tasks, typically six to twelve items, that must be completed for each Product Backlog item.  Generally, a DoD for a software team will include technical tasks such as design, analysis, coding, testing, review and some form of documentation.

The DoD applies uniformly to all Product Backlog items and remains non-negotiable even when the team, or organization, is under pressure due to time constraints. The Scrum Guide enforces two restrictions related to the DoD:

1. Product Backlog items that fail to meet the DoD cannot be released to customers or end users.  This ensures that the customers and end users always receive a high-quality, usable product.  One way to visualize your product is to think of it as a meal and the DoD as the ingredients.  Ideally, you would be proud and confident to serve the product to your family because the ingredients, i.e., the DoD, are of high-quality.  However, if you would not feed the product to your dog, then it does not deserve to be served up to the customers and end users, i.e., no Squirrel Burgers.
2. Product Backlog items that fail to meet the DoD cannot be demonstrated at the Sprint Review.  This prevents the Scrum Team from offering misleading indications of progress and discourages them from compromising on quality in order to meet a deadline.  While these items may not be demonstrated at the Sprint Review, the Scrum Team must reveal why the DoD was not met.  This is to ensure the impediments are revealed and addressed by the stakeholders.

The DoD is owned collectively by the Developers and they are “required to conform to the Definition of Done” at all times.  In scenarios when there are multiple Scrum Teams working together on a single product, “they must mutually define and comply with the same Definition of Done.”  

Acceptance Criteria Defined

Acceptance criteria (AC) is the information provided to the Scrum Team, often by the Product Owner, to ensure that a Product Backlog item has been implemented correctly and fulfills the relevant function and non-functional requirements.  Clear and unambiguous AC are very important for Scrum Teams to prevent misunderstandings and delays.

For example, suppose we are working to develop an ordering system.  One AC to this system could be that when a customer submits an order, they receive a notification.  However, there are many different ways to implement this AC – email, phone call, or text message.  Therefore, in this example the AC would need to be clarified to include how the notification will be delivered.

Distinguishing DoD from Acceptance Criteria

Now that we have defined DoD and AC, let’s explore the difference between the two, because Scrum practitioners confuse these concepts.  Here are three distinctions:

1. AC documents how the product was designed to meet the customer’s and end user’s needs, i.e., the extrinsic quality of the product.  DoD documents what are the engineering tasks the Developers followed to build the product, i.e., the intrinsic quality of the product.
2. AC are specific to individual Product Backlog items and are owned by the Product Owner.  DoD applies universally and is owned by the Developers.
3. AC describes how customers or end users would validate if the value contained in the Product Backlog items has been delivered to them.  DoD describes how the business would verify if the product was built according to their quality standards.

Another error many Scrum practitioners often make is to include the AC as part of the DoD.  In effect, requiring customer needs to be satisfied as a precursor to releasing the Increment.  While this is a noble objective, it has some drawbacks:

• It is superfluous. For Developers which need help to reinforce good habits related to their technical practice (test-driven development, automated integration tests, code reviews, etc.) or working together as a team, the DoD can serve as a convenient repository to store their commitments.  However, if your Developers need a reminder to “satisfy the needs of the customers and end users,” then your Scrum Team has a bigger problem that can be resolved with a DoD.
• Stalls momentum. For teams which use Scrum to build software, the first responsibility of the Developers is to develop a high-quality product Increment which conforms to the DoD.  For teams that do Scrum well, they have a regular rhythm of delivering high-quality Product Backlog items and making progress on their Product Backlog.  However, if meeting the AC is part of the DoD, what are we to do in the scenario when a customer or end user interacts with the software and they decide their needs have NOT been met?  I would propose the Scrum Team is “done” because they delivered the customer’s original request.  In this scenario, the customer has introduced a change request based upon interacting with the final product.  This change request may, or may not, be added to the Product Backlog depending on the upcoming Sprint Goal(s) and Product Goal.  By separating intrinsic quality (good engineering) from extrinsic quality (customer satisfaction), we enable the Scrum Team to make regular progress on their deadlines.  If we do not, Product Backlog items are never closed and the Scrum Team never gets into a winning cycle.
• Creates confusion on who owns intrinsic quality.  When AC are included in the DoD, this gives the impression that customers, end users and stakeholders define technical quality.  Doctors don’t allow their patients to define what is standard practice related to their treatments, so why should customers, end users or stakeholders define (or adjust) technical quality for the Scrum Team?  In Scrum, the intention is to give Developers the authority to set intrinsic quality, to set that level high and allow that level to remain undisturbed throughout the Sprint.  Building high-quality software that can change over time requires skill, concentration, and time and space to think.  

Now that we have reached the end of this article, I hope you have a clearer understanding of the nuances associated with the DoD and how the DoD can be used to foster change.  By adhering to the principles of usable and “in use” and differentiating the DoD from the AC, Scrum Teams can improve the quality of their delivery while they maximize customer satisfaction.