What is the difference: Acceptance Criteria vs. Definition of Done?

We would like to clarify a couple of often misunderstood concepts: the difference between Acceptance Criteria and Definition of Done. In many organisations, these two are confused, there is no clear boundary between them, even though they have completely different meanings and serve different purposes.

User story

In an Agile environment, where the nature of the product and the structure of the organisation allows, we use User stories to formulate requirements. The User story format is a child of Extreme Programming (XP) and is particularly suited to formulate needs and requirements from the perspective of the future user of the product, an approach that can be very helpful in maintaining the right focus and attitude.

The User story is a lightweight format that focuses more on purpose and less on detail. It is designed to help both business and delivery to come to the same understanding of the purpose of a task, and to select and implement the most appropriate solution. The User story does not include implementation details, but focuses only on articulating business objectives.

A user story typically consists of three parts:

1.Agile or header sentence, which states that:

– from whose point of view the need is being written (persona),
– what is the interaction that the persona wants,
– and last but by no means least: why does he or she want this? What is the purpose of it?

E.g. “I, as a cardiologist doctor, would like to have a list screen of my patients because I would like to see who are the ones who might be suitable to participate in a research programme for an experimental medicine.”

2. Description: this is where we list the information behind the idea, the details.

E.g.: “list screen, with the following attributes (columns), columns should be in order, I should be able to select multiple items from the list at once (multiselect), page breaks should occur every 20 hits, I should be able to navigate between the hit pages, names should always start with a surname, without a prefix (e.g. Dr., etc.)

 3. Acceptance criteria

What is Acceptance Criteria?

Acceptance criteria is when a requirement written in User story format is supplemented with a short, core set of criteria that the development must meet. These criteria can be simple or complex sentences of a bulleted nature. E.g.:

– I see my patient name on the list screen,
– On the list screen I see the date my patient was admitted to the department,
– I can see my patient’s drug sensitivity (if any) on the list screen
– I can sort the list screen according to all three attributes
– The list screen has a page break every 20 items

The Acceptance Criteria is therefore a functional list of criteria. For each requirement (User story) there are Acceptance Criteria, and they are different for each requirement, according to the content of the requirement.

It is important that the Acceptance Criteria no longer includes new information that may not have been included in the header sentence or description. The acceptance criterion should only reflect the content of these two.

It is also important not to write Acceptance Criteria for every detail. The so-called Miller cycle, which is also used for agile team sizes, i.e. 7 +/-2 pieces, applies here too. If there are more Acceptance Criteria than this, it implies that our User story is too big and further fragmentation is needed.

The Acceptance Criteria helps developers and testers to achieve the goal set out in the User story and to validate its achievement.

What is the Definition of Done?

Definition of Done is the non-functional list of criteria that each requirement/need (User story) that passes through the hands of the team must meet at the end of the iteration.

So, while there is an Acceptance Criteria for each User story, and they are different and specific, a team or product has only one Definition of Done, and it applies to each User story.

Imagine a guard standing at the door where we release our small implementations, our packages, and checking them. The guard does not inspect the content and functionality of each package, but only checks that they meet the general criteria.

In Definition of Done, we distinguish between the following 6 categories:

– Code quality expectations
– Developer testing expectations
– Functional testing requirements
– Documentation requirements
– General business requirements
– Non-functional requirements

Sticking with our example above, a product development team producing such a list screen can typically operate with a Definition of Done like the following:

E.g.: in case of a backlog item:

– must be committed to the integration branch 
– code review done successfully
– tests run successfully, test report attached
– relevant documentation updated/prepared
– prepared for demo (test data, installation, etc.)
– in the task tracking system, its tasks are in Done state. There are no open tasks.

Another example of the difference between Acceptance Criteria and Definition of Done

Let our product be a mobile app that helps users practice reading music. One element of the product’s backlog could be the following User story:

What would a User story look like?

– Me, as a beginner pianist
– I would also like to practice on violin and bass clef sheet music
– In order to learn to blatt in both keys.

Acceptance Criteria example

The story’s Acceptance Criteria can be for example:

– When you start practising, the application asks you in which clef you want to practise (violin/bass)
– Position the notes according to the selected clef
– When scrolling the sheet music, the clef does not scroll, it is fixed at the beginning of the line

Definition of Done example

Since the Definition of Done applies to the whole product, to all backlog elements of the product, it contains more general expectations, e.g:

– All changes are committed to the main branch
– All interfaces comply with the UX guideline
– All screens of the application can be used in both portrait and landscape mode (full screen content is visible, all interactions are available, …)

 

By: Schweinitzer Zoltán, Sprint Consulting