What is the difference between the definition of done and acceptance criteria? If a team has let this question fester for any length of time, they generally will decide that the two concepts are synonymous. Unfortunately they are wrong.
The definition of done is the requirements that the software must meet to be considered complete. An example of the definition of done is:
All stories must be unit tested, a code review performed, integrated into the main build, integration tested, and release documentation completed.
Almost every team has a different definition of done, as technology, business or government requirements or organizational culture can have an impact on how a specific team implements the definition. For example, a team building software or hardware for use in a medical device will have different regulatory requirements they must adhere to. The definition of done is generally agreed upon by the entire core team at the beginning of a project or program and stays roughly the same over the life of the project. It provides all team members with an outline of the macro requirements that all stories must meet. Therefore the definition helps in estimating by suggesting many of the tasks that will be required. I have heard the definition of done described as the requirements generated by an organizations policies, processes and methods For example the organization may have a policy that requires code to be scanned for security holes. This requirement would need to be in the definition of done.
Acceptance criteria, on the other hand, provides confirmation that the story does what was intended and can be used to create an acceptance test. An example of acceptance criteria for a simple ( a more robust version of this example was shown previously ) data entry screen for a logo glass collection application would include:
- Brewery name is a required field.
- Glass logo copy is a required field
- Glass type is a required field
The software must meet these criteria in order to meet the Product Owner and stakeholder needs. During a hands-on demonstration the Product Owner and stakeholders would be able to execute these functions. Acceptance criteria are a part of the description of the stakeholder’s requirements for the software.
In order to be part of a demonstration where the story can be accepted, all stories must satisfy both the definition of done and the acceptance criteria. The definition of done provides the team with a clear understanding of their obligations to meet overall organizational and process requirements. Acceptance criteria define how the Product Owner and stakeholders will know that the story meets their requirements for a specific function. Both are required for the team to understand when a story is done.
December 19, 2013 at 4:19 am
I find it handy to think about the DoD conditions as Verification (have we built it right?) and acceptance criteria as Validation (have we built the right thing?), as per Barry Boehm. That way we focus on both intrinsic and extrinsic quality and don’t deliver one at the expense of the other.
December 19, 2013 at 9:41 am
Nicely said. Arguably it would be easy to be pushed to trade one for the other.
December 19, 2013 at 9:27 pm
Farnam Street has written a far better review of Scotts’ book than I ever could do, you can find it here:
http://www.farnamstreetblog.com/2013/12/scott-adams-fail-at-everything/
December 19, 2013 at 9:31 pm
That will teach me to try writing something before my morning coffee! I’ve replied to the wrong post, will now try to untangle things.
June 28, 2014 at 11:57 pm
[…] each piece of work according to the definition of done. #NoEstimates makes a strong case that unless done means anything other than usable by the end […]
September 29, 2014 at 11:55 pm
[…] securing video or telecom facilities, publishing an agenda with breaks and more. 3. Review the definition of done. Ensure that everyone understands the organization’s definition of done before the starting to […]
December 1, 2014 at 11:55 pm
[…] mitigation for common risks into the definition of done. – The definition of done is the requirements that the software must meet to be considered complete. Common risks such as the […]
October 24, 2017 at 11:55 pm
[…] The nuance in the question centers on the phrase “hardening and other security requirements.” There are two approaches that I often use for stories with nonfunctional requirements. The first (and not my favorite) is through a final hardening sprint. The second approach is splitting the user stories into thin slices and then incorporating the nonfunctional requirements into the definition of done. […]