Definition of Done

The “Definition of Done” is a formal description of quality criteria for the Scrum teams to have a shared understanding of what “Done” means for 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:

1. Eat the dinner with: A soup, starters, main course, desserts
2. Washing hands
3. Keeping leftover food into fridge
4. Adjust the chairs at the dining table
5. Cleaning the utensils
6. Cleaning the dining table
7. Switch off the light and fan/air conditioner in dining area
8. 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”?

The “Definition of Done” is a “commitment” for the Product Increment. That means, each Increment that is created in a Sprint should meet the “Definition of Done”. It is a formal description of quality criteria checklist. The purpose of the Definition of Done is to decide whether a Product Backlog Item can be made part of an Increment or not. It helps achieve a shared understanding between the Product Owner and the Developers 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 Developers. 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 Scrum Team (Product Owner, Scrum Master and Developers) together create the Definition of Done that helps them to create a potentially releasable product increment. They should have a shared understanding on 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 first Sprint begins. It helps the Developers to forecast work for the upcoming Sprint. 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 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 should conform to the “Definition of Done”?

The Developers are responsible to conform to 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?

1. All acceptance tests must pass
2. Unit testing done
3. Unit tests must be automated
4. Functional testing done
5. ZERO S1 or S2 defects
6. Code review done
7. Code review feedback implemented
8. Code refactored
9. Code must be integrated into main branch
10. Integration testing done
11. Integration issues fixed
12. Documentation done
13. Performance testing done
14. Stage testing done
15. Live like testing done
16. Security testing done
17. OS compatibility testing done
18. Browser compatibility testing done
19. Mobile and web compatibility testing done
20. Product owner approved the item