What is the difference between user story and acceptance criteria?

Definition of Done (DoD) is a list of requirements that a user story must adhere to for the team to call it complete. While the Acceptance Criteria of a User Story consist of set of Test Scenarios that are to be met to confirm that the software is working as expected.

The difference between these two is that the DoD is common for all the User Stories whereas the Acceptance Criteria is applicable to specific User Story. Acceptance Criteria of each User Story will be different based on the requirements of that User Story.

In other words, Both DoD and Acceptance Criteria must be met in order to complete the User Story. The Product Increment is not considered to be complete, unless both these two lists are done. Thus, we need to define two aspects of the Definition of Done (DOD) — Completion Criteria and Acceptance Criteria:

Definition of Done

  • 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

The goals of Definition of Done

  • Use as a checklist that User Stories (or PBIs) are checked against
  • Ensure the increment shipped at the end of the Sprint has high quality and that the quality is well understood by all involved.

Example — Definition of Done

For example, in the software industry, teams may need to ask some of the following questions to come up with their DoD:

  • 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 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

The goals of Acceptance Criteria

  • Ensure everyone has a common understanding of the problem
  • Help the team members know when the Story is complete
  • Help verify the Story via automated tests.

Example — Acceptance Criteria

  • Information from the form is stored in the registrations database
  • Payment can be made via credit card
  • An acknowledgment email is sent to the user after submitting the form

Example of User Story with Acceptance Criteria


IT professional