Definition of Done vs Acceptance Criteria in Scrum

The completion definition (DoD) is a list of requirements that the user story must comply with so that the team can invoke it as complete.

The acceptance criteria for user stories include a set of test scenarios that will meet the requirements to confirm whether the software works as expected.

When will the user story be completed?

In other words, in order to complete user stories, DOD and acceptance criteria must be met. Product increments are not considered complete unless both lists are completed. Therefore, we need to define two aspects of DoD definition — completion criteria and acceptance criteria:

Definition of Done

The definition of Done is structured as a list of items, each one used to validate a Story or PBI, which exists to ensure that the Development Team agree about the quality of work they’re attempting to produce. It serves as a checklist that is used to check each Product Backlog Item (aka PBI) or User Story for completeness. Items in the definition of “Done” are intended to be applicable to all items in the Product Backlog, not just a single User Story.

It can be summarized as following:

• The term applies more to the product increment as a whole
• In most cases, the term implies that the product increment is shippable
• The term is defined in the Scrum Guide
• Used as a way to communicate among the team members
• Overall Software Quality
• Whether the increment is shippable or not

Example — Definition of Done

• Code peer reviewed?
• Code completed?
• Code reviewed?
• Code checked-in?
• Unit tests passed?
• Functional tests passed?
• Acceptance tests completed?
• Product Owner reviewed and accepted?

Acceptance Criteria

User stories are one of the primary development artifacts for Agile development, but Scrum doesn’t explicitly require either User Stories or Acceptance Criteria to be used. If a product backlog item is consider to be too big to be put into a sprint, will normally be broken down into user story and subsequently into a set of tasks as shown in the Figure:

User Stories encapsulate Acceptance Criteria, thus we often see the definition of done and acceptance criteria co-existing in our scrum development process. User story provides the context of the functionality the team should deliver. The acceptance criteria gives guidance about the details of said functionality and how the customer will accept them. The two of them together provide the whole deliverable.

Some of the Acceptance Criteria will be discovered in Ongoing Backlog Refinement events before the Sprint starts, and others will be discovered right after Sprint Planning when sit down to have a conversation about the user story in a small team. So Acceptance Criteria are attributes that are unique to the User Story or Product Backlog Item.

• The term applies to an individual PBI/Story
• The Acceptance Criteria are different for each PBI/Story
• Term is not defined in the Scrum Guide
• Used as a way to communicate to all involved that the requirements for a particular PBI/story have been met
• Aka Acceptance Tests, Conditions of Satisfaction, in some cases “Test Cases,” etc

Example of User Story with Acceptance Criteria

The figure below shows an example of acceptance criteria of a user story.