Definition of Done vs. User Stories vs. Acceptance Criteria

One of the more frequently asked questions in my Scrum workshops is around the difference between Definition of “Done” and Acceptance Criteria, and how they relate to User Stories.

While Acceptance Criteria is a commonly understood concept in software development, Definition of “Done” is unique to Scrum. People get confused between these two things but they’re distinctly different, and it’s important to know how to tell them apart so they can be used effectively. This post will help you better understand each, as well as User Stories, and their unique roles and relationships with each other in the context of Scrum.

Since both Definition of “Done” and Acceptance Criteria apply to User Stories, let’s make sure that we understand User Stories first.

User Stories

A User Story is a tool to move the focus from What we’re building (what often happens with traditional requirements) to Why and Who. It’s intended to start a conversation between the people who will implement the Story and the Product Owner, with the goal of ensuring the Team solves the underlying business problem instead of just delivering a requirement.

The goals of a User Story are:

• to focus on the business problem that needs to be solved, not the solution to that problem.
• to start a conversation about why a problem needs solving, who needs it, and what problem to solve.
• to demonstrate a need in as concise and simple a form as possible.
• to be a small, vertical slice of functionality – if we were making a cake, this is something that goes through all the layers – as opposed to delivering only the icing. In technical terms: through the entire system, not a description of the component layers or technical need (as illustrated by the picture). Traditional approaches often describe work to be done in technical layers (e.g. Business Logic or Database). This leads to waste in the form of Over Production. User Stories avoid this waste by challenging teams to build only the pieces in each layer required at that moment.

Since User Stories are not official Scrum tools, there is no required format, but a common structure is “As a <role> I want <to do> so that <value>”.

The three components of User Stories, often referred to as the three C’s, are:

•  Conversations: Conversations that discuss the Story details and result in creating the acceptance criteria.

•  Confirmations: Acceptance criteria that, in software, can be turned into automated acceptance tests.  These automated tests enable the simple and light approach implemented by the other two C’s.

•  Card: A token (with a Story title/description, traditionally written on a small paper card or sticky note), used for planning and acts as a reminder to have conversations.

Here is an example of User Stories for an imaginary Point-of-Sale system. The user is denoted as a Buyer.

As a buyer, I want to pay by tapping my debit card so that I spend less time in the checkout process.

As a buyer, I want to be able to enter my pin code when transactions are over $100 so that I know that I’m secure if my card is stolen.

As a merchant, I want debit cards to be checked to ensure that they’re valid so I don’t lose money by accepting invalid cards.

Each User Story (sometimes called a Product Backlog Item or PBI) and its associated Acceptance Criteria (we’ll cover them last) are then checked against the Definition of “Done” to ensure correctness and completeness.

Definition of “Done”

The Scrum Guide, in a way that is maddeningly vague, says that:

When a Product Backlog item or an Increment is described as ‘Done’, everyone must understand what ‘Done’ means.

I promise you, that sentence and the paragraphs that follow are the most poorly understood aspects of the Scrum Guide. Some Team members will assume “Done” means it works on their machine. Others will believe it means they throw their work over the wall to Quality Assurance or Test. Still others will assume that “Done” is limited to checking in working code. Since the Scrum Guide is so vague, Teams need to establish their own shared understanding of what they will call “Done,” and put it in writing so it’s clear.

That’s why the Definition of “Done” exists: to ensure that the members of the Development Team and the Product Owner (PO) agree about the quality and completeness of the work they’re producing. Used effectively, the PO will know that, if the Team can show that they have met the list of conditions of “Done,” then the PO can safely deliver the product to the client.

This is intended to be applicable to all items in the Product Backlog, not just an individual User Story.

Here is an example of a simplified Definition of “Done” from the World’s Smallest Online Bookstore that we use as a model in our Scrum by Example series:

Item

Whenever changes are made to existing code, a Unit Test is written to cover that method

Usability Review Completed

Tested on iPad, iPhone and Android Phone

Performance Tests run

Code Peer Reviewed (if not written using Pair Programming)

End-User Documentation has been updated

The Definition of “Done” is different from Acceptance Criteria because “Done” doesn’t change from one User Story to the next, while the Acceptance Criteria is written specifically and uniquely for each individual feature or User Story. It also differs in that it has a formal Scrum definition, whereas Scrum doesn’t require either User Stories or Acceptance Criteria to be used.

To summarize, the goals of “Done” are:

• to build a common understanding within the Team about quality and completeness.
• for that understanding of “Done” to include the Product Owner.
• to be a checklist that User Stories 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.

Acceptance Criteria

While a User Story is deliberately vague to allow the Team freedom to decide the precise details of how something will be built, Acceptance Criteria are the precise details. They are unique to each User Story. (For more details on how and when the Acceptance Criteria are discovered see: the Lifecycle of a User Story and Acceptance criteria)

The goals of Acceptance Criteria are:

• to clarify what the Team should build before they start work.
• to ensure everyone has a common understanding of the problem.
• to help Team members know when they should cease work on a Story. This is distinct from “Done” because they may have met the acceptance criteria but not checked everything against “Done.”
• to help verify the Story via automated tests.

An example of Acceptance Criteria:

This User Story:

As a buyer, I want to pay by tapping my debit card so that I spend less time in the checkout process.

results in the following Acceptance Criteria:

Tap limit is $100
Tap not allowed under $10
Linked account is checked to ensure the balance is sufficient

The trouble with Acceptance Criteria written in a plain English format, as above, is that they’re full of ambiguity. So, a popular approach to describing Acceptance Criteria is “Specification By Example”, also known as Behaviour Driven Development (BDD) or Acceptance Test-Driven Development (ATDD).

User Story: Tap Credit Card
Acceptance Criteria:

Sale Amount	Bank Balance	Expected Result	Expected Message
$0.00	$99.00	Fail	No purchase
$9.99	$99.00	Fail	Below minimum threshold for tap
$10.00	$99.00	Pass
$90.01	$90.00	Fail	Purchase over the amount of money in the account
$100.00	$100.00	Pass	No numbers
$100.01	$200.00	Fail	Purchase is over the maximum tap limit

Conclusion

Definition of “Done” is the global requirement checklist for all User Stories. Acceptance Criteria are the specific details needed to complete a User Story. A User Story is a placeholder for a conversation about meeting a User need.