The Scrum Guide has a Definition of “Done” (DoD) which is a shared understanding in the team to assess when work is complete on the product Increment.
Everyone must know what the Definition of “Done” is and the team will cross-check the agreed criteria against the completed product backlog item (PBI).
The Scrum Guide also states: “Product Backlog items often include test descriptions that will prove its completeness when “Done”.” This will be Acceptance Criteria which is a common practice but not explicitly mentioned in the guide.
Think of the Definition of Done as a consistent set of Acceptance Criteria that applies to all backlog items.
The DoD adds transparency to the process and must be visible to everyone, whether in a software tool or on a Kanban board. It should be refined through inspect and adapt cadences where to the Retrospective is also a good opportunity.
The Scrum Guide states: “If the definition of “Done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.”
Conceptually the definition of done is a checklist of the types of work that the team is expected to successfully complete before it can declare its work to be potentially shippable. Most of the time, a bare-minimum definition of done should yield a complete slice of product functionality that delivers validated customer value.
At the most abstract level, a definition-of-done checklist might include: Designed, Built, Integrated, Tested and Documented.
To help with how to construct the DoD, think about breaking it down in to 3 components, as will help shape the desired criteria:
1. Business or functional requirements
2. Quality
3. Non-functional requirements
Business or functional requirements
The stakeholders input will be at the Product Increment level to gather their shared understanding. Indeed to reaffirm, the DoD is taken at the Product Increment level, not at the product backlog level, that is the Acceptance Criteria. Therefore this falls into business or functional requirements.
Quality
This will be the developments teams realm.
Components of quality will include, Test Driven Development, User Acceptance Testing, Peer-Review, Regression Testing, Smoke Testing, Technical Debt, Unit Testing, Device Testing and so on.
Non-functional requirements (NFRs)
NFRs represent important system-level constraints that affect the design and testing of most or all items in the product backlog. Non-functional requirements are used to specify various characteristics such as system performance for example, Accuracy, Portability, Reusability, Performance, Reliability, Security, Usability, Maintainability, Interoperability, Capacity, Platform, Scalability, Compliance, Regulatory, Legal and so on.
An NFR can be an attribute of either product quality or product scope.
An NFR can be added as a PBI or Acceptance Criteria or in the DoD.
If the NFR relates to all the PBIs then list it within the Definition of “Done”.
If the NFR must apply to each and every product increment, then it expresses a quality concern which may reasonably be observed via the Definition of Done. Otherwise it may reasonably be held to constitute product scope, and ordered on the Product Backlog accordingly.
Definition of “Done” example for a software product
For a software product, the definition of “Done” might include by Nick Butler:
| Tests written and passing | 𝥀 |
| Continuous Integration build passing | 𝥀 |
| Cross-browser testing done on current top 5 browsers according to analytics | 𝥀 |
| Mobile testing done on current top 3 mobile devices according to analytics | 𝥀 |
| Google accessibility check passed | 𝥀 |
| Code peer-reviewed | 𝥀 |
| Documentation updated | 𝥀 |
| Acceptance criteria met | 𝥀 |
Resource
- Article: DONE Understanding Of The Definition Of “Done” by Sumeet Madan