Acceptance Criteria and Definition of Done. What is the difference?

A User Story is an invitation to a conversation.

It requires Acceptance Criteria and a Definition of Done. What is the difference?

As an Agile Coach I meet many people and work with several teams. I’ve noticed that a lot of people in these teams mix up Acceptance Criteria with the Definition of Done.

Traditional requirements cover what needs to be built.

User Stories move the focus to why and who.

A User Story is intended to start a conversation between the people who will implement the Story (the ‘development’ team) and the Customer/Product Owner. During the conversation the Agile team identifies things needed to make that User Story meet the ‘condition of satisfaction’ of the user. The goal is to ensure that the team solves the underlying business/customer problem instead of just delivering a requirement.

A User Story is a small vertical slice of functionality through the entire system.

The ‘conditions of satisfaction’ are called Acceptance Criteria. They are story specific “requirements” that must be met for the story to be completed. Acceptance Criteria are often added during backlog refinement or during the sprint planning meeting. The Acceptance Criteria add functional details to the user story and provide a convenient guide for testing the completeness of the story/feature. Therefore Acceptance Criteria, the set of statements, each have a clear pass/fail result. There is no partial acceptance: either a criterion is met or it is not.

The goals of Acceptance Criteria are to:

• clarify what the team should build before they start work
• ensure everyone has a common understanding of the problem
• help the team members know when the Story is complete

Some examples of acceptance criteria:

• No password longer than 16 characters should be allowed
• VAT should be included in all figures

If you want a term to describe when a Story meets its acceptance criteria, maybe “complete” or “accepted” are better terms than “done.”

This brings us to ‘Done’, sometimes referred to as ‘Done-Done’.

The Definition of Done is a list of things that need to be completed for any story to be considered done.

The Definition of Done is agreed by the team prior to starting work. It is a set of quality criteria, usually non-functional criteria, for work they are attempting to produce. ‘Done’ is structured as a list of items that are used to check the quality of each User Story to be able to release this feature. The items in this list represent ‘conditions of satisfaction’ for all stories. There is no partial acceptance: either a criterion is met or it is not. Some refer to this as ‘Done-Done’, as in really done.

The goals of the ‘Definition of Done’ are:

• to build a common understanding within the Team about Quality and Completeness
• to be a checklist that User Stories (or PBIs) are checked against
• to ensure the increment shipped at the end of the Sprint has high quality and that the quality is well understood by all involved

Examples might be:

• Regression testing completed
• User documentation updated to reflect new story
• Seen by and approved by the Product Owner
• Performance testing benchmark achieved
• Architecture updated
• Peer reviewed

The difference between the two is functional versus non-functional.

The functional conditions are things that the users may notice, like password criteria or error messages.

The non-functional conditions usually consist of things, like code reviews and unit tests, which are measures to ensure a high quality product.