Done vs. Acceptance
The topic of Done Criteria and Acceptance Criteria can be confusing to many teams, especially during the beginning of their Agile journeys. This article explains the concepts and lists the differences between “Done” and” Acceptance” with examples.
One of the objectives of Scrum is to create a potentially shippable product increment after every sprint. The word “potential” implies that the decision to release or implement a product implement belongs to the business and not the development team. Many factors influence that decision and usually software / product release happens at cycle intervals that are different to Sprint intervals.
Potentially shippable refers to a state of confidence in what was “done” during the sprint and implies that important work that needed to be done during the sprint was not omitted. To determine whether the output of a sprint is potentially shippable, the Scrum team must have a well-defined and agreed definition of done. This is called the “Done Criteria”.
The “Done Criteria” is a checklist of the types of work or key activities that the Scrum team is required to successfully complete before it can assert that the work is potentially shippable.
An example of a typical checklist for “Done” is illustrated below in Fig 1.
Fig 1: Example of “Done Criteria Checklist”
Done Criteria depends on a number of factors such as;
Type of product being developed
Technology being used to develop it
Policies, procedures and standards of the organization developing it
Development approach
Impediments impacting the development process
Etc.
Regardless, it is important to define the minimum set of “Done Criteria” such that the product functionality of feature that has been developed in any sprint is designed, built, integrated, tested, documented and delivers customer value. Often, some broadly defined criteria such as “Testing” may need to be defined more specifically to include as an example, performance testing. Other times a broad definition may suffice. Further, “Done Criteria” may vary from Sprint to Sprint. As an example, it may not be necessary to carry out certain types of testing such as Regression testing or Performance testing in every sprint. However, it is important to note that it is good practice to not compromise on any essential activity during a Sprint and for that reason a good, agreed-upon definition of “Done Criteria” by the team and stakeholders.
Acceptance Criteria
Acceptance criteria are different to Done criteria and are specified at Product Backlog (item-specific) level by the Product Owner as conditions of satisfaction. Acceptance criteria are typically verified in acceptance tests that will be confirmed by the Product Owner. As an example, a Product Backlog Item or User Story relating to an “online payment being made by a credit card” may have acceptance criteria stating that the function should work with Visa, Mastercard and Amex. In general, each product backlog item may have its own set of acceptance criteria.
Acceptance Criteria should be used in addition to Done Criteria and not in instead of. In the above example of the online payment with a credit card, the typical unit and functional testing that would be carried out could potentially return a “no defect” all clear result and yet in a live environment a customer’s payment through an Amex may fail if it had not been explicitly included as part of the Acceptance Criteria. In order to avoid any potential confusion between Acceptance criteria and Done criteria it may be useful to call refer to Acceptance criteria that have been fulfilled as “Completed” or “Accepted” instead of as “Done”.
Best practices for creating Acceptance Criteria
Every Backlog Item (User Story or Epic) should have at least one Acceptance Criteria, if not more
Acceptance Criteria should be identified before starting development work on the item
Acceptance Criteria should be independently testable
Every Acceptance Criterion should have a clear Pass / Fail result
Acceptance Criteria should focus on the “what” (end result) and not the “how” (solution)
Acceptance Criteria should include functional and non-functional criteria
The Scrum team may write the Acceptance Criteria in consultation with the Product Owner, however the Product Owner should validate them.
Example of Acceptance Criteria
Fig 2: Example of Acceptance Criteria
Summary
A Scrum team’s definition of “Done” is a set of criteria that is agreed upon and must be met before any Product Backlog Item (User Story) can be considered complete. These set if criteria depend on a number of factors such as the product being developed, technology used in the development, organizational processes and standards and constraints.
In contrast, “Acceptance” criteria are special conditions of satisfaction that are specific to a given backlog item and may include functional and non-functional criteria.
Acceptance criteria are used in addition to Done Criteria and one does not substitute the other.
