Definition of Done: Example, Checklist and Workshop in Scrum
I recently prepared a workshop with a colleague. In terms of content, we quickly agreed on what it should be about, all that was missing was a Powerpoint presentation. In order to be able to work on the presentation as efficiently as possible, we divided it thematically. When we sat down to talk through the finished draft, a major problem emerged: We had very different ideas about what a “finished draft” actually was.
This problem can also arise with agile scrum teams. A team can come to the end of the sprint after two weeks, but could still be at a disagreement as to whether the product can already be finished, and moved from “in progress” to “done”. This disagreement leads to discussions, which in turn could negatively affect the climate in the team. To prevent these discussions and to protect effective teamwork, there is an artifact in the scrum world called “Definition of Done” (DoD).
What is the Definition of Done in Scrum?
The Definition of Done is the Scrum Team’s shared quality agreement. It describes which conditions must be met for an increment to be considered done and usable. It is not a personal task list and not an additional acceptance by a single role, but a transparent standard for the entire team.
Literally, as well as in agile, the definition of done means “what it means for something to be finished”. So it’s about a team agreement on what needs to be done for a feature to be considered finished. In practice, the definition of done can be presented as a kind of checklist, which is used during the sprint and especially at the end to check whether certain completion criteria have been met. For software development teams, these criteria could include the following:
Definition of Done Example: Checklist for Scrum Teams
A practical Definition of Done can include the following criteria for a software product, for example:
- The acceptance criteria and functional requirements are met.
- Documentation was created.
- The code is fully implemented and annotated.
- A code review was carried out.
- Automated tests run successfully; relevant bugs and security risks have been addressed.
- The change is integrated and can be verified in a production-like environment.
- Monitoring, logging, and, where applicable, release notes have been taken into account.
- The increment is usable and meets the product’s quality standard.
- …
This list is an example, not a universal template. A good DoD protects quality, remains applicable for the team in every Sprint, and is adapted when the product, risks, or technical conditions change.
The Definition of Done is not the same as product impact
A Definition of Done answers an important question: Does the increment meet the agreed quality standard and is it usable? But it does not automatically answer whether the change delivers the desired impact in the market or for the customer.
For practice, it therefore helps to distinguish between three levels:
- Done: The increment meets the Definition of Done and can be used.
- Done-Done: The change is integrated, released, and observable in operation.
- Product impact: Real customer feedback shows whether the change solves a relevant problem and increases product value.
John Cutler therefore describes software as a continuously evolved services system: features are not final buildings, but temporary means of creating customer value. Read his perspective in The Work Is Never Done.
Gil Zilberfeld also distinguishes between different meanings of “Done” – for example when development, testing, delivery, or customer feedback each mark a different degree of completion. You can find his classification in The Definition of Done, Done-Done and Really Done.
Important: “Product impact” should not simply be formulated as an additional DoD criterion. A Scrum Team must deliver a usable increment; whether it achieves the desired impact is then revealed through the Sprint Review, usage, and further learning loops. This very distinction protects the Definition of Done from becoming an unattainable checklist.
We show how the Definition of Done works together with other effective Scrum practices in our article Scrum Best Practices 2026.
Why is a definition of done important?
The fact that setting goals is of enormous importance for performance is not particularly new knowledge. Goal setting is a highly researched topic in psychology (cf. Locke & Latham, 2006). It has been shown that performance is at its highest when goals are formulated as specifically as possible, and challenging without appearing unattainable. However, the definition of done is not a method of goal setting (but if you need support with goal setting , we are here to help); it is rather about criteria that must be met in order to achieve your goal.
These criteria are important in order to create a common understanding within the team. An understanding of what each team member has to do to achieve a common goal. So it’s about individual achievements that ultimately combine to form a team effort.
If you look at the topic of DoD from the perspective of a product owner, completely different problems emerge. If it is not clearly defined when a product increment is considered finished, there may be inconsistencies when the product is presented to the client. If this happens and an incomplete product is presented, it is unlikely that you can get feedback form your client anymore.
Continuous improvement
Since a definition of done is not a static concept, i.e. it can and should be continuously developed or changed, it also offers the team the opportunity to learn. If the team notices at the end of a sprint that they could not meet the criteria of their original definition of done, the team members can either adjust the final definition to accommodate their performance, or draw conclusions to begin their next sprint and change their way of working.
Test Echometer for free now & get new inspiration for your retrospectives!
The team should carry out these “definition of done” reflections as part of the retrospective. Possible echometer itemsthat can be queried in the preparation stages are:
We have clear definitions of done for our requirements.
I usually know where we are in achieving our common goals.
My goals are aligned with the goals of my colleagues.
The team covers all the skills we need to achieve our goal.
They not only question whether there is a definition of done in the team at all, but also how transparency, autonomy and role clarity are in the team.
You can find the complete item pool in our Retro tool.
How can our team define “done”? An example of a workshop
We showed you what a definition of done is, and why it is important for effective collaboration in scrum teams. However, if your team has not yet created a DoD, you may still be wondering how it works.
In principle it is important that the team spends quality time on the setup. At the end, a document should be created with which each team member can identify, and which is not only seen as a necessary evil. That is why we recommend a workshop-like format with a scrum master as moderator. Each team member should think about which criteria are important for the completion of the product, and the team can summarize these thoughts together. Similarly, we have developed a workshop format for goal setting. Take a look hereto get ideas for your definition-of-done workshop!
The completed DoD can be used in retrospectives, for example in the form of the definition of done traffic light:
- Write down your criteria for the definition of done as a list.
- Draw a red, a yellow and a green field next to each criteria.
- For each point of the definition of done, each team member marks whether it was implemented well in the last sprint, average or badly.
- Discuss the three with the most frequent answers in the red area.
- If necessary, adjust your definition of done.
Conclusion - Done?
Using few words to conclude: there is no such thing as “finished” in an agile environment. Done simply means that something is ready for the time being, but further adjustments and improvements can and should follow at any time. That is one of the many beautiful aspects of agile work: continuous improvement.
What can be particularly suspenseful is that sometimes points are “done,” until the client then questions the whole solution and shakes up your foundation of assumptions about customer needs. In such situations, it can be seen whether the team has really prioritized customer benefits over progress in the ticket system.
A clear definition of done can avoid conflicts and increase your performance. If you are interested in other ways to achieve this goal, you should also check out our article “the amazing truth behind the agile mindset” . Or enrich your retrospectives by taking into account the latest scientific findings from the field of psychology.
It was with this promise that we developed our retro tool Echometer. If you are interested in how (and whether) Echometer works, please read Holger’s experience with our tool:
Do you want to take your team to a performance level? Our retro tool can help you. Here are Holger’s experiences with it:
Holger’s report on the remote retrospective toolFrequently asked questions about the Definition of Done
What belongs in a Definition of Done?
A Definition of Done includes all quality criteria that an increment must meet in order to be usable. Typical examples are met acceptance criteria, code review, tests, security checks, documentation, and the technical ability to deliver. Which items apply is decided by the team for its product context.
Who creates the Definition of Done in Scrum?
The Scrum Team develops and maintains the Definition of Done together. It should not be prescribed by a single role as a control list. Organizations may define minimum standards, but the team must understand them and be able to apply them in everyday work.
What is the difference between Definition of Done and Definition of Ready?
The Definition of Done describes when an increment is finished and usable. A Definition of Ready, on the other hand, can contain criteria for preparing a work item, but it is not an official Scrum artifact and must not be used to shift responsibility or feedback loops.
Practical example: Our internal Definition of Done at Echometer
A Definition of Done does not have to end with code and tests. Internally, Echometer uses a more comprehensive standard that, in addition to functionality, also takes UX, maintainability, observability, and release preparation into account. The following example shows how a team can make its own quality criteria concrete and verifiable:
| Area | Example criteria |
|---|---|
| Functionality | The specified feature works, typical edge cases have been checked, there are no known bugs, unfinished features are protected by a feature flag, and relevant usage data is collected. |
| UX | Empty states, loading states, permissions, error handling, localization, and responsive presentation have been taken into account. |
| Maintainability | Coding guidelines and relevant conventions have been followed, unnecessary code and deliberately left technical debt have been avoided, and important information for monitoring and debugging is available. |
| Deployment | The change has been rolled out to production or deliberately prepared via a feature flag, release notes have been added, and affected stakeholders are informed if needed. |
This example is of course not a universally valid template. But you can use it as a basis, flesh it out with your own definitions, review it regularly, and continue to develop it as a living document.
References
Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x
