The “Definition of Done” is a quality criteria for the Scrum teams to have a shared understanding of what “Done” means for a Product Backlog Item (PBI) or the Increment. This is the most confusing topic also for most of the Scrum teams. So in this article, I am attempting to make this concept clear through a simple example.
Let us take a scenario: What is the criteria that helps you to decide whether your family dinner is “done” or not? Below will be the probable criteria:
- Eat the dinner with: A soup, starters, main course, desserts
- Washing hands
- Keeping leftover food into fridge
- Adjust the chairs at the dining table
- Cleaning the utensils
- Cleaning the dining table
- Switch off the light and fan/air conditioner in dining area
If the above criteria is met, then the dinner can be considered as “Done”. If any of the above items are not done then the dinner is not done.
What is “Definition of Done”?
It is a quality criteria checklist. The purpose of the Definition of Done is to create a potentially releasable product increment. It helps achieve a shared understanding between the Product Owner and the Development Team on what “Done” means. This quality criteria can be different for different types of Products. For example, if you build a house, the quality criteria may be different than building a software Product.
What is the difference between Acceptance Criteria and Definition of Done?
The Acceptance Criteria is related to the functionality whereas the Definition of Done is related to the Quality. For example, in the above “dinner” scenario, what items have to be consumed for dinner will be the acceptance criteria and it will be decided by the Product Owner. But the quality criteria will be decided by the Development Team. Acceptance criteria can vary for different Product Backlog items but the quality criteria will be mostly same for all the Product Backlog items.
Who will create the “Definition of Done” and when?
The majority of the criteria items will be proposed by the Development Team as they have to create the increment and they should know what kind of quality criteria the increment should have. The Scrum Team together agrees to the Definition of Done and typically if it is created before the Sprint begins, it helps the Development team to forecast work for the upcoming Sprint. it also helps the Scrum Team to have a common understanding of the “Done” criteria. The Scrum Master facilitates the creation of the Definition of Done. If the organization has any pre-defined quality standards such as “for every 5 KLOC there will be only 3 severity 1 defects” then those standards must be included in the definition of done and on top of that, the Scrum team can choose additional criteria.
Is “Definition of Done” static?
No, the Definition of Done can change based on the need. Sprint Retrospective is a formal opportunity for the Scrum Team to inspect and adapt their Definition of Done”. As the Scrum Teams mature, their “Definition of Done” should be more strengthened. If the Definition of done gets changed, then the previously completed increments’ features must be brought to the current Definition of Done.
Can different teams work on the same Product have different “Definition of Done”?
The “Definition of Done” is applied for the entire Product Backlog or the Increment. So if there are multiple teams working on the same Product, then they should have a mutually agreed common “Definition of Done”. On top of that each team may add some additional items that may be specific to their team. However, when any team says they are “Done” with an item, that item must satisfy the common definition of done agreed by all teams. This ensures the same level of quality is maintained by all teams.
Who owns the “Definition of Done”?
The Development Team owns the “Definition of Done”. They must ensure every item they work on the Sprint should satisfy all the criteria of their “Definition of Done”. There will be no one to supervise or validate this but it is the Development Team’s responsibility to ensure all items that are worked within a Sprint should meet the “Definition of Done”.
What is a weak “Definition of Done” and what are the consequences of it?
Anything less than the ideal definition of done will be considered to be a weak definition of done. For example, the ideal definition of done should contain 25 criteria to create a potentially releasable increment, but due to many challenges such as skills, infrastructure or tools the team has agreed less than 25 criteria as their definition of done then it is a weak definition of done. If the team starts with a weak definition of done and builds more features using the weak definition of done, eventually it may lead to technical debt and it makes the Product unstable. So in that case, the Scrum Master should help the team understand the consequences of weak “definition of done” and help them address those challenges and to make the definition of done stronger as soon as possible.
What can be a sample “Definition of Done” for a Software Product?
- All acceptance tests must pass
- Unit testing done
- Unit tests must be automated
- Functional testing done
- ZERO S1 or S2 defects
- Code review done
- Code review feedback implemented
- Code refactored
- Code must be integrated into main branch
- Integration testing done
- Integration issues fixed
- Documentation done
- Performance testing done
- Stage testing done
- Live like testing done
- Security testing done
- OS compatibility testing done
- Browser compatibility testing done
- Live like testing done
- Product owner approved the item