Getty Images/iStockphoto
How to compare acceptance criteria vs. definition of done
Acceptance criteria and the definition of done both measure quality in product development, but the ways teams calculate and achieve these features vary dramatically.
In the Scrum world of Agile development, acceptance criteria and the definition of done are two ways that teams assess the quality of their product and its readiness for deployment. While they both quantify software quality, the ways each standard assesses quality are vastly different.
Acceptance criteria are the main conditions and standards laid out by the user that a piece of software must meet before it reaches deployment. The definition of done, on the other hand, is a comprehensive list of standards and characteristics that must be met before a project or the user story is considered done or complete and ready for further development.
Teams should understand the difference between acceptance criteria and the definition of done and the role each plays in the development and testing processes.
When are acceptance criteria and the definition of done defined?
Teams should define both variables as early as possible in the product increment. They should define and review acceptance criteria when they write a user story, preferably before they accept it into the backlog. When teams define acceptance criteria this early, it facilitates backlog grooming and improves the velocity of the user story.
Teams should develop the definition of done during product increment planning. The definition of done outlines an agreement for team members that they adhere to during the development process. It should be part of every team member's onboarding, and all team members should understand their individual responsibilities and commitment to meeting the definition of done.
Acceptance criteria vs. definition of done similarities
The main similarity between the definition of done and acceptance criteria is that they both provide an objective measure of a product's quality. Both measures offer transparency into what the team needs to accomplish for the product increment release.
Another similarity between the two is their use of the user story. Before teams finalize any user story, they need to ensure it meets both the definition of done and acceptance criteria.
Acceptance criteria vs. definition of done differences
The main areas where acceptance criteria differs from the definition of done are their quality assessment, scope and creation.
Quality assessment
One of the most important differences between acceptance criteria and the definition of done is the aspect of quality that each measures. Acceptance criteria assess the quality of the user story development. They evaluate whether the feature described in the user story meets the user requirement.
The definition of done is organized into a checklist that ensures that the team has applied the proper development and testing processes. Some example components of this checklist are the following:
- has it passed design and code reviews;
- have unit and functional tests passed; and
- has testing covered all acceptance criteria.
Scope
Teams develop and test acceptance criteria for each user story individually, whereas the definition of done applies to the product increment. Therefore, the definition of done serves as an overall check on quality. Even when each user story meets its acceptance criteria, the team could miss processes that could significantly affect the quality of the increment.
Creation
Although the Scrum team creates both acceptance criteria and the definition of done, different members of the team play different roles in each process.
Product owners serve as the user voice. They create the acceptance criteria with the help of other members of the team. Quality engineers ensure that the acceptance criteria are specific and testable. Developers provide input on how to limit code complexity.
Creating the definition of done is a team effort. Product owners, Scrum Masters, developers and quality engineers must agree. They decide on processes, how to use the processes during iteration, how to follow those processes and how the processes assess quality.
How do they fit into the testing process?
Both acceptance criteria and the definition of done serve as quality gates in the test process. Whereas the acceptance criteria serve as the quality gate for the user story, the definition of done serves as the quality gate for the product increment.
If the acceptance criteria are not fully met, the team might have to extend the user story into the next sprint or possibly into the next increment. If the definition of done is not met, the team could push out the entire product increment, which delays the development schedule, pipeline and other features in the backlog.
