Are you new to Agile with Scrum? Or, have you followed this methodology for a while but you’re having trouble determining when a user story is really complete? Do you have a Definition of “Done”? Most teams create user stories with at least some Acceptance Criteria but don’t go the extra step to create a Definition of Done. In addition, some teams don’t understand the difference between these two concepts.
The Definition of Done lets the team know that a story has not only met its individual goals, but is also complete on a higher level. The Acceptance Criteria describe the objectives a story must meet to be completed, but a Definition of Done shows the story is “Done Done,” meaning it is a potentially shippable increment of value. So, the short answer to the how the Definition of Done differs from Acceptance Criteria is the Definition of Done applies to all stories whereas Acceptance Criteria applies only to the individual story.
What is the Definition of Done?
The Definition of Done identifies the mutually agreed-upon criteria that define when work is completed. Here’s Agile Alliance’s definition: “The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment ‘often a user story’ is considered ‘done.’ Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity.”
The 2020 Scrum Guide describes it as “a formal description of the state of the Increment when it meets the quality measures required for the product.”
Why is it important?
The value of the Definition of Done is that it provides transparency to the team by confirming when work is completed. It’s important that teams deliver value with each sprint, but how do you truly know if it’s complete? The definition of done sets those guidelines.
What is the value of creating it?
- Aligns expectations
- Helps to improve quality
- Avoids unfinished work
- Provides a common definition of when work is to be considered complete
- Since it defines specific expectations for when work is completed, it can limit conflicts between the business and development teams.
What are its characteristics?
- Generic
- Achievable
- Transparent
- Risk-Reducing
- Ensures standards are followed
- Can include non-functional requirements
- Defines when a story/feature is completed
- Mutually defined by the teams
Who defines it?
The team or teams working together must all mutually agree on the definition.
When is Done defined?
- Before work begins on the sprint
- The definition of Done is continuously refined as the team’s skills and technologies evolve.
Examples:
At the team level, Done can include the following:
- Story satisfies acceptance criteria
- Code is peer-reviewed
- Story is accepted by the Product Owner
- Manual testing is complete
- Automated testing is complete
- Non-functional requirements are met
- Code is in the required repository and under version-control
- Security requirements are met
- System architectural guidelines are followed
Acceptance Criteria
What are they?
Acceptance Criteria are specific to each story. Acceptance Criteria ensure the story as implemented satisfies the functional and non-functional criteria as specified by the Product Owner. They also provide the story details from a testing point of view. They must be testable and can be simple statements, or they can follow the Behavior Driven Development format of Given-When-Then.
When are they created?
They are created as the story is written and they are unique to each individual story (as opposed to the Definition of Done, which applies to all stories).
Who creates them?
The Product Owner, with assistance from the development team.
What do they look like?
- Example User Story: “As a bank customer with an ATM card, I want to withdraw cash from an ATM so I do not have to wait in line at the bank.”
- Given-When-Then format:
- Given that the account is active and the card is valid and dispenser contains cash…
- When the customer requests cash…
- Then ensure the account is debited for the amount withdrawn and ensure the cash is dispensed and ensure the card is returned.
- Simple Statements:
- When the user inserts the card, it must be validated.
- Once the card is validated, confirm the account is active.
- After the customer enters the amount to be withdrawn, confirm the account has enough funds to complete the transaction.
- After the customer enters the amount to be withdrawn, confirm the dispenser has enough cash to complete the transaction.
- Ensure the funds are debited from the account.
- Verify the cash has been dispensed.
- Return the card to the user.
Definition of Done vs. Acceptance Criteria Summary
Acceptance Criteria
- Are specific to the story.
- Ensure the story as implemented satisfies the functional and non-functional criteria.
- Are created in sprint planning.
Definition of Done
- Created by the team or teams working together on the same project
- Applies to all stories; not story specific
- The story is complete only when the Acceptance Criteria and Definition of Done are satisfied
I hope this post helped you understand how the Definition of Done lets your team know when a story has met its individual goals and is also complete at a more significant level. The Acceptance Criteria describe the objectives a story must meet to be completed, but a Definition of Done indicates when the story is “Done Done,” that is, when it is a potentially shippable increment of value. If you have any additional questions around Acceptance Criteria or the Definition of Done, please don’t hesitate to reach out to us at any time. We’d love to help you get started.
by Mike Kushner

Mike Kushner is a Scrum Master and Senior Program/Project manager with over ten years of experience in Agile and Scrum. Mike’s solid background in application development as an IT consultant enables him to lead business and technology teams to implement key corporate projects with consistent success.
© 2000 - 2021 Anexinet Corp., All rights reserved | Privacy Policy | Cookie Policy