The Definition of Done often gets confused with the Acceptance Criteria. Acceptance Criteria is specific to a user story and it will differ from one user story to the next as it’s tied to a particular functionality or feature. The acceptance criteria further clarifies the feature by proving context and intent. It helps manage expectations and conditions of satisfaction. It might lead to new features. It is objective, tangible and measurable. It tells us when a requirement is complete.
The Definition of Done is about the team’s quality checklist. It’s more about how we as a team build a quality product irrespective of the particular requirement or feature. It applies to all user stories, and it includes things like checking-in the code, verifying that unit, integration, system, and acceptance tests pass, verifying performance and load tests pass, etc… Whatever it takes to get an item to “Done” as agreed to by the team. Many times, I see these listed as acceptance criteria when they should really be part of the team’s working agreements represented by the Definition of Done. This ensures the entire team including the product owner have the same understanding of “doneness” and the quality expected for all product increments resulting from user stories regardless of the specific feature.
Check out the Definition of Done canvas to help you and your team create an effective Definition of Done.
