Exploring the Difference: Definition of Done vs Acceptance Criteria

As a Professional Scrum Trainer and a Scrum Master, I often get this question - What is the difference between the Definition of Done and Acceptance Criteria? Though the question might sound very simple to some, it still exists, appears now and then on many platforms, and at times is a point of discussion.

Let me start with a short and smart answer that was once shared with me by a fellow PST, and then I will dive into some more explanation on each term.

Short Answer

Definition of Done is about building the product "right," and Acceptance Criteria is about developing the "right" product.

Long Answer

Let us explore what it means to build the product "right" and develop the "right" product. Product Development (software or otherwise) is a process of value creation. However, the value is only realized when the product is made available to end-users. How do we know that the product we are creating is good enough to be made available to end-users? It is where the concept of Acceptance Criteria and Definition of Done become decisive factors.

What is Acceptance Criteria

The concept of Acceptance Criteria comes along with User Stories from Extreme Programming. Typically, a User Story is a short 3 line description expressing a requirement from the customer's perspective.

For any additional details, the Developers would collaborate with the business (customer) and understand more. During such a conversation, they (developers and customers) agree upon the requirement's acceptable behavior. This agreed-upon confirmation of the requirements behavior is termed as Acceptance Criteria. 

A User Story is deemed complete if it satisfies the acceptance criteria stated for the functionality's behavior. There could be one or more Acceptance Criteria for any user story. 

Example of a User Story:

As a consumer

I want to add products to my cart.

So that I can purchase them

How do we know that this User Story is acceptable to businesses? Probably, the simplest thing to do here is to display the product in the shopping cart after it's added.

But that alone may not be enough to meet the business needs fully. The acceptance criteria could just verify the item shown in the cart. However, more criteria may be needed.

The developers and customers can work together to identify other conditions to satisfy the user story.

By collaborating, they can define all the necessary acceptance criteria. This helps ensure the user story aligns with business expectations before it's considered complete.

For examples:

Acceptance Criteria:

1. Added products are visible in the customer cart.

2. The cart value is updated to show the sum of all products added.

3. Customers can now check out the products.

4. The link to removing the product is activated on the cart.

5. The link to change the quantity of the product is activated on the cart. 

Developers can now use these Acceptance Criteria to write their automated Acceptance Tests, which would validate the requirement's behavior.

But is this enough to release the product to end-users? How do we know that this newly created functionality will not break any existing functionality or make the product vulnerable to security threats, or will not bring down its performance?

meeting acceptance criteria alone doesn't mean the story is ready for release. Other checks are needed to prevent regressions, security issues, or performance problems. This is where the "definition of done" comes in - it expands on acceptance criteria to fully confirm releasability.

What is the Definition of Done

Definition of Done helps determine the "DONENESS" of product increment that we develop during an iteration or a sprint as a team. It helps us make explicit the quality of our product increment. 

If a product increment does not meet Done's Definition, it is not ready for release to end users. This is because it lacks sufficient quality. Testing is essential for ensuring quality. Therefore, completing all required testing should be part of the definition of done.

A typical Definition of Done may look like a checklist about the quality of the product. 

Example

1. Code is reviewed.

2. Code is manually tested in dev and test environments.

3. All code is integrated frequently.

4. Integration testing is performed.

5. SonarQube check is run to determine the code metrics

6. Refactoring is done.

And for teams that are just starting, it can be elementary and minimalistic, for example:

1. All acceptance criteria are met.

2. Testing is done.

However, launching a product increment to the end users often involves more than just code quality. Other aspects need to be considered as well before a release.

For example, in highly regulated domains like finance or healthcare, meeting compliance and regulatory requirements is essential. These must be part of the definition of done.

Thus, the Definition of Done includes aspects of code quality and has to include all the aspects of product quality. An example of such a Definition of Done could look like:

• All acceptance criteria are met (product quality).

• All acceptance tests are automated (code quality).

• Release notes are made available (product quality-compliance need).

• Developers follow a test-driven approach to development (code quality).

• Code reviews are done (code quality).

• With every commit, SonarQube gets executed (code quality).

• With every commit, an automated build gets executed (code quality).

• User documentation gets created (product quality).

• The color guide (product quality) is followed.

• Font family and font size consistency to be maintained (product quality).

When You Should Create Your Definition of Done vs. Acceptance Criteria 

The Definition of Done is established upfront, before development starts, and remains consistent over the course of the project. The product owner and team align on the definition of done early on and revisit it periodically to keep it current. 

On the other hand, acceptance criteria are created collaboratively for each user story during iteration planning sessions and backlog refinement. The product owner and team discuss and agree on acceptance criteria when detailing out stories to prepare for upcoming sprints.

 The acceptance criteria are recorded directly with each user story, rather than in a separate overarching document. They may evolve iteratively as more is learned about how to satisfy the user story.

What are the Similarities Between Definition of Done and Acceptance Criteria

The Definition of Done and acceptance criteria are similar in some aspects but serve different purposes:

Similarities:

• Both define conditions for work to be considered complete

• They promote alignment on quality standards

• They enable validation through testing

• They drive collaboration in defining done criteria

• They create transparency into progress

Differences:

• The Definition of Done is overarching, applying to all work

• Acceptance criteria are specific to individual user stories

• The Definition of Done is defined upfront and stable

• Acceptance criteria are created just in time per story

• The Definition of Done focuses on high-level quality standards

• Acceptance criteria define detailed functional behaviors

So, although both of them serve different purposes, they complement each other to provide complete and high-quality work. 

Wrapping Up

The definition of done and acceptance criteria are different, but they are used for complementary purposes. The Definition of Done provides overarching standards for completeness and quality that apply broadly across all work. Acceptance criteria offer detailed specifications that are unique to each user story.

By differentiating between these two artifacts, teams can ensure holistic criteria for high-quality done work from both macro and micro vantage points. Leveraging both in tandem enables organizations to deliver high-value increments with maximum alignment, transparency, compliance, and quality baked in at multiple levels.