As an Agile practitioner, I often encounter confusion regarding the terms “acceptance criteria” and “definition of done.” Individuals frequently inquire about the distinctions between these two concepts and whether they can be used interchangeably. This misunderstanding is prevalent and warrants clarification to ensure effective communication and application within Agile frameworks.
Let’s look at the details.
Definition of Done:
The Definition of Done (DoD) is a clear, agreed-upon checklist of criteria that a product or increment must meet to be considered fully completed. The definition of Done applies to the entire product Increment and does not apply to a Product Backlog item (or Epic/Feature/Story).
According to Scrum.Org, The Definition of Done is the commitment by the Developers for the Increment, much like the Sprint Goal is the commitment by the Developers for the Sprint Backlog and the Product Goal is the commitment by the Product Owner for the Product Backlog.
The Definition of Done includes all of the characteristics and standards an Increment needs to meet to be released. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed and what standards were met as part of the Increment.
If a Product Backlog Item does not meet the Definition of Done, it cannot be released yet. Think of the Definition of Done as the standards set for the products delivered.
The development organisation usually creates the Definition of done; if there is no definition at the organisation level, the development team can create its own.
Examples of definitions of done:
⇨ No critical or major defects will be accepted.
⇨ The code must undergo peer review.
⇨ The code must be unit-tested.
⇨ Code coverage must be at least 80%.
⇨ All web pages should load in under 5 seconds.
⇨ The code must run on both Windows and Mac machines.
⇨ All acceptance criteria must be met.
⇨ User documentation must be complete, and release notes should be prepared and ready to be shipped with the increment.
⇨ The support handover (if any) must be completed.
Acceptance Criteria:
You won’t find any mention of Acceptance Criteria in the Scrum Guide. Acceptance criteria are optional and serve as a complementary practice borrowed from XP (Extreme Programming). They apply to Product Backlog items (user story) and pertain to the desired functionality of those items.
In essence, Acceptance Criteria are a set of predefined requirements that must be fulfilled for a user story to be considered complete. Each user story in the sprint backlog can have multiple Acceptance Criteria associated with it. Some recommend having no more than 1–3 acceptance criteria per user story. If a user story has more than 4–5 acceptance criteria, it might be better to split the story as there is a risk that a big user story can’t be completed in a single sprint.
Why should we have Acceptance Criteria?
▻ Defining the scope of a user story and reducing ambiguity.
▻ Clearly specify what needs to be developed by the development team during the sprint.
▻ Establish testing criteria, as they serve as a reference for developers to understand the functional requirements and for testers (within the development team) to ensure that these requirements are met.
▻ Sometimes, to capture non-functional requirements such as reliability, availability, scalability, usability, and maintainability.
▻ A guiding light for a product owner to either accept or reject a user story
Examples of acceptance criteria:
▻ The password must be no less than 8 and no greater than 12 characters.
▻ It (password) should contain at least one uppercase letter, one lowercase letter, and one special character.
▻ Users can not submit the registration form without filling in all mandatory fields.
▻ Payment can be made via either a VISA or Mastercard.
▻ Users should get an email when their account is created in the system.
▻ Password field values should not be shown as plain text.
▻ Users should receive push notifications when a new message is received.
▻ Results should be displayed within 5 seconds after the search is executed.
Conclusion:
The main difference between the definition of done and acceptance criteria is their scope and purpose in evaluating completed work. Both concepts are essential for determining whether a specific product feature is finished, but they operate on different levels.
The definition of done encompasses a broader perspective, serving as a checklist that applies to the entire product increment. It includes criteria that must be met across all features to ensure the overall quality and readiness of the product for release.
On the other hand, acceptance criteria are much more focused and detail-oriented. They pertain specifically to individual user stories, outlining the conditions that must be satisfied for that particular feature to be considered complete.
In summary, while the definition of done sets the standard for the overall product, acceptance criteria provide the specific benchmarks for each user story.
Suggestive Reading:
☞ User Stories Applied: For Agile Software Development by Mike Cohn
☞ Agile Estimating and Planning by Mike Cohn
☞ Online Scrum.Org Resources
Leave a Reply