Acceptance Criteria and Definition of Done

February 25, 2016
Elrich Faul
Planning, Sprint
2 Comments

I have observed a tendency in Scrum teams to easily get confused between the role of Acceptance criteria and the Definition of Done. Although theory easily differentiates between the two I try to clarify the difference between the two in a more creative and maybe more tangible way in this post.

Acceptance Criteria

According to Kenneth S Rubin:

Acceptance criteria define desired behavior and are used to determine whether a product backlog item has been successfully developed.

Acceptance criteria play a big role in the Definition of Ready. The Product Owner compiles a set of criteria in collaboration with the stakeholders to clearly define their need as well as the value presented by each feature. It consists of all the information needed by the Development team and the Product Owner to get a clear picture of what needs to be done. Once this picture becomes clear, the next step will be to ask how it can be accomplished.

This set of criteria should be comprehensive enough to be an input for the creation of comprehensive tests and the delivery of a piece of functional code. Test Driven Development empowers a team to ask these questions well. Developers often ask how to identify what to write tests for. The acceptance criteria should answer this question. The functionality and value for the stakeholders should be the guiding compass. This also prevents the team from stepping into the pitfall of vanity metrics (measurements that give “the rosiest picture possible” but do not accurately reflect the key drivers of a business).

A possible pitfall is that the acceptance criteria becomes a set of specifications. The product owner needs to produce comprehensive stories that do not constrain the innovation and creativity of the developers.

Some examples of Acceptance Criteria:

A user cannot submit a form without completing all the mandatory fields.
Information from the form is stored in the registrations database.
Protection against spam is working.
Payment can be made via credit card.
An acknowledgment email is sent to the user after submitting the form.

Definition of Done

According to Kenneth S Rubin:

Conceptually the Definition of Done is a checklist of the types of work that the team is expected to successfully complete before it can declare its work to be potentially shippable.

The Definition of Done is the overall criteria that need to be completed for a sprint and inherently each story to be complete. I refer to it as a common denominator. Let me use an example to better illustrate. If there are Acceptance Criteria that are common to all the stories, that criteria can rather become part of the Definition of Done.

An example of a Definition of Done would be something as follows:

All functionality should be tested
The goal should be reached
Documentation should be up to date

If for instance, a story needs to be deployed to QA before it can be seen as completed, and that specific acceptance criterion is applicable to each of the stories, it will become part of the Definition of Done. As the common criteria become transparent, the Definition of Done will dynamically change and grow. The Definition of Done becomes an input for the weighting of stories as described in my post on weighting.