Get 200 Real Life User Stories
Examples Written by Mike Cohn
I'd like to clarify the relationship between two important concepts: a team's Definition of Done and the Conditions of Satisfaction (or Acceptance Criteria) for a user story. Let's start by reviewing each of these concepts.
What Is the Definition of Done?
The definition of done is an agreed-upon set of things that must be true before any product backlog item is considered complete. Let me say that a bit differently: every product backlog item for a particular product must satisfy the definition of done criteria to be considered potentially shippable.
What Are Some Definition of Done Examples?
Every team's definition of done will be slightly different, but a good starting point might be: 
- the code is well-written. That is, the team does not feel they need to immediately refactor or rewrite it.
- the code is checked in.
- the code comes with automated tests at all appropriate levels.
- the code has been either pair programmed or has been code inspected.
- the feature the code implements has been documented as needed in any end-user documentation.
Who Creates the Definition of Done?
The developers (aka the development team) create the definition of done through a shared understanding of what it means to create a high-quality, shippable product in their context. The definition of done applies to all product increments the team creates and complies with organizational standards of quality. The definition of done may also contain additional elements that are unique to that product.
What Are Conditions of Satisfaction?
In contrast, conditions of satisfaction are specific to a given product backlog item and define what must be true for that particular product backlog item to be considered done.
Acceptance Criteria vs Conditions of Satisfaction
Many people call conditions of satisfaction, acceptance criteria. And that's perfectly OK. I prefer to ask for conditions of satisfaction vs acceptance criteria for one reason: it makes more sense to product owners. And product owners are the people primarily responsible for creating conditions of satisfaction.
Product owners (and some programmers) consider writing acceptance criteria to be something specific that testers do. When I ask them to write the acceptance criteria for a user story, many product owners seem confused, saying they don't know how to write tests for code.
Product owners have a much easier time answering the question if I avoid the term acceptance criteria. So instead I ask them, what needs to be true in order for you to consider this particular story done? And we capture those as conditions of satisfaction.
What Are Some Examples of Conditions of Satisfaction?
To understand the difference between conditions of satisfaction and definition of done, it might be helpful to look at some examples. Consider a user story such as, "As a user, I am required to login before using the site." That user story might include these conditions of satisfaction:
- user is logged in only when proper credentials are provided
- a "remember me" option is available
- user can request a password reminder
- user is locked out after three failed attempts
For this example user story to be done, all of these conditions of satisfaction must be true and the team's definition of done must also be true.
Acceptance Criteria vs Definition of Done
Acceptance criteria and conditions of satisfaction (CoS) are two terms that mean almost the same thing. When it comes to product owners writing CoS for user stories, it's perfectly fine to call those conditions acceptance criteria. So acceptance criteria have the same relationship to definition of done as conditions of satisfaction do.
Think of the definition of done as a special set of acceptance criteria (aka conditions of satisfaction) that are added to every user story (product backlog item). For the user story above to be done, two things must be true. 1) All of the acceptance criteria (conditions of satisfaction) must be fulfilled, and 2) All of the items that make up the definition of done must be complete.
Because I like to write user stories on the front sides of index cards and the conditions of satisfaction (acceptance criteria) on the back sides, I tend to think of the definition of done as something I have written on a custom-made rubber stamp. I could then stamp each user story card with those items in addition to the hand-written acceptance criteria for this specific story.
What Do You Think?
How do you view the difference between the acceptance criteria for a product backlog item and a team’s definition of done. Please share your thoughts in the Comments section below.
