Acceptance Criteria and the Definition of Done
Recently some of the teams I’m coaching found it difficult to distinguish between acceptance criteria for user stories and the definition of done. Here’s my attempt to make the distinction clear:
- For a user story or feature to be “potentially shippable” it needs to meet the expectations of the Product Owner and be of the agreed quality.
- The Product Owner’s expectations are phrased as acceptance test criteria. Acceptance test criteria are conditions of satisfaction specific for each individual user story. (For more on acceptance criteria read “On Acceptance Criteria”).
- The user story’s (internal) quality is defined in the “Done” statement. The “Done” statement is applicable to all user stories in the project.
Here’s an example:
“As a music lover I want to be able to pay for my album by VISA card”
Example Acceptance Criteria (specific for this story):
- I can purchase an album by VISA card
- I cannot pay with a VISA card that’s expired
- I cannot pay with a VISA card with a wrong number
Example Definition of Done (DoD) (valid for ALL stories):
- 0 (known) bugs
- Passed unit tests
- Passed automated Cucumber acceptance tests
- Passed cross browser testing
- Passed UAT
- Code peer reviewed (if not pair programmed)
- Relevant documentation updated
The “Definition of Done”(DoD) is the team/project’s quality statement for a user story or feature and ensures that a feature is 100% developed and tested. It is a statement that no more work is left to be done on this piece of functionality (90% done doesn’t count!) and that it works without errors.