by Jason Gardner (Ed.)
Two important components to consider when working with a scrum product are the Definition of Done (DoD) and Acceptance Criteria (AC). At first, it might seem like these two are interchangeable, but that is not the case. Each has a distinct purpose, and their combination is what ensures that Scrum teams deliver a potentially shippable product increment. In this article, we’ll look at what the definition of done and acceptance criteria are, their differences, and why scrum teams need both.
What is Definition of Done:
The definition of done (DoD) is a shared and agreed-upon checklist of criteria that must be met to consider the product increment ready for release. The idea is that every team member understands what quality means, and they know what a product increment looks like when it’s “done.” It’s a list of quality standards, and it’s important to set these standards so that team members are on the same page and can communicate better.
The team agrees upon the criteria that must be satisfied before the product increment is ready for release. The criteria usually include various aspects like functional requirements, performance standards, usability, security, and more. For example, a marketing team may have a definition of done that states that outgoing materials follow the organization’s style guide. A software team may have a definition of done that says that all checked in code must have unit tests.
What is Acceptance Criteria:
While the definition of “done” is the shared understanding of what quality means and how to assess it, the acceptance criteria are different. Acceptance criteria (AC) are a set of criteria that are used to define the boundaries or scope of a user story. They represent the requirements for a single user story, and they are drafted during sprint planning. Acceptance criteria work best when they are customer focused, and allow the team to figure out the best technical solution to implement. Instead of saying, “User records will be stored in a MySQL database and use AES encryption”, say, “User records should be stored in a database with passwords following industry standard encryption practices.”
The acceptance criteria represent the implementation-specific information necessary to satisfy each user story. That is, if every acceptance criterion is satisfied, then the user story is complete. The acceptance criteria must be clearly articulated, so both the team members and stakeholders agree prior to the start of a sprint.
Why Do We Need Both?
So why do we need both DoD and ACs? The answer is that the definition of done is essential for achieving a potentially shippable product increment. Without a definition of “done,” the team members may deem their work complete when it is not acceptable for a client. It would result in increased cycle times, make it more difficult to scale development, and increase the likelihood of defects. The DoD looks at the whole increment and its overall quality, while the AC are about defining specific elements of the product increment.
When used in tandem, the DoD and ACs help ensure that deliverables from each sprint meet the highest standard of quality and meet customer needs. By agreeing upon standards beforehand, the DoD ensures that the team knows from the outset what their work must achieve. ACs help ensure that the team knows precisely what they must deliver to meet a particular user’s requirements. In short, the DoD asks “when are we done?” whereas the ACs ask, “are we doing the right thing?”
Conclusion:
In conclusion, it’s important to understand the difference between the definition of done and acceptance criteria and understand how to apply them properly. The DoD and ACs are two distinct concepts that serve to define the quality of the product increment as a whole and for each user story, respectively. Their combination is what ensures that the product increment delivered by the Scrum team is of high quality and solves customer needs. By being clear about what “done” means and what they are expected to deliver at the beginning, the team can work collaboratively towards the common goal and be more efficient in their development processes.
