It was once odd to me that we need to define this. However, lessons learned (that I caused, in fact) have impressed upon me that what I think is done may not/is not the same as the Development Team, Product Owner, Stakeholders, nor perhaps the Sponsor (the big cheese 🧀) themselves. That said, this is an important step. It only takes one misunderstanding before you, too, will see its importance.
<aside> 💡 Each team member may have a different understanding of “work completed” for the team’s deliverables. [A Scrum Book]
</aside>
There is an expanded article I wrote on this subject here.
**Ryan’s Definition of Done:** The agreed-upon state (via the entire Scrum Team) of a Backlog item that does not require any more work to be finished.
Modified from the 2020 Scrum Guide 👇
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the organization’s standards, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done considered appropriate for the product.
The Developers are required to conform to the Definition of Done. If multiple Scrum Teams are working together on a product, they must mutually define and comply with the exact Definition of Done.
You can create your Definition of Done any way you want. However, I recommend using a checklist. This allows you to literally go down the list to see if you meet your definition. Here’s an example,
Meta-physical World Creation DoD Checklist