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.
Definition of Done is about building the product “right,” and Acceptance Criteria is about developing the “right” product.
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.
As a consumer
I want to add products to my basket.
So that I can purchase them
How do we know that this User Story is acceptable by business? Probably, the simplest thing to do here is to display the added product in a basket. Thus, the Acceptance Criteria could be as simple as
- Added products are visible in the customer basket.
Is this enough? Maybe or maybe not. In either case, the developers and customer can collaborate to identify many more acceptable conditions, which would then become our Acceptance Criteria. For examples:
- Added products are visible in the customer basket
- The basket value is updated to show the sum of all products added.
- Customers can now check out the products.
- The link to removing the product is activated on the basket.
- The link to change the quantity of the product is activated on the basket.
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? Maybe, maybe not. 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?
It is where comes the Definition of Done.
What is 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 to use and could not be released to end-users. It also means that there is not enough quality on the Product Increment. Quality needs testing, and thus testing is an integral part of the Definition of Done.
A typical Definition of Done may look like a checklist about the quality of the product.
- Code is reviewed.
- Code is manually tested in dev and test environments.
- All code is integrated frequently.
- Integration testing is performed.
- SonarQube check is run to determine the code metrics
- Refactoring is done.
Or for teams that are just starting, it can be elementary and minimalistic, for example:
- All acceptance criteria are met.
- Testing is done.
However, to launch a product to the end-user often is not enough. Only the quality of the code doesn’t guarantee that increment is releasable. At times there are other aspects that need to be considered. For example: if the product is from a domain that is highly regulated, such as finance or medical, then all the necessary compliance/ regulatory aspects also need to be part of your 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 Test Driven approach for 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 is followed (product quality).
- Font family and font size consistency to be maintained (product quality).
Definition of Done and Acceptance Criteria are two different things and serve different purposes. While Definition of Done focuses on the quality aspect of the product increment, Acceptance Criteria focuses on the completeness and behavior of the product increment’s functionality. Also, we need to remember that quality is not just about the “code”; it is about its usability.
An enabler; helping teams in their journey to pursue agility. I believe that happy teams build happy products. Build teams around motivated individuals is my daily mantra. He is having having fifteen years of experience in the industry and have donned various roles earlier.