Definition of Done (DoD) | David Tzemach
One of the main things we need to do when building an Agile culture is to decide on the “Definition of Done” criteria. It allows the company to ensure all stakeholders are familiar with the criteria, which must be met before a feature/user story is considered “Done.”
Who Determines the Definition of Done Criteria?
The Definition of Done (DoD) should be one of the main starting points for Agile projects involving different stakeholders. The Product Owner and the team should always work together to agree on a clear “Definition of Done,” which will define whether a story/feature is ready as an increment delivery.
Interpretation of the Definition of Done Among Teams
During the years, I have seen different interpretations of how to determine DoD. One common way to do it is to state that the development is finished once the testing is conducted. In this case, the team says, “a story is completed only when the tester in the team says it’s done.” If that is how you decide to do it in your team, you must ensure the tester is the focal point of the PO, so the team understands the PO’s intentions.
For me, this method of “Tester” approval is less effective for several reasons:
Single point of failure.
Developers may ignore their responsibilities (Why shouldn’t they if they can always blame the tester).
It creates a logical separation of testers and developers.
The more common (and far more effective) way to implement DoD is to use checklists that specify the criteria and requirements needed for completing a feature, Sprint or story.
How the Definition of Done Affects Team Velocity?
The definition of done affects team velocity. Failure to meet the agreed criteria at the end of the development sprint implies the team has failed to complete all tasks related to the story. Therefore, that story should not be counted toward that sprint’s velocity.
Why Do We Need a Definition of Done?
It provides a simple checklist, which simplifies the development activities of coding, estimation, design etc.
It helps increase visibility and transparency.
It reduces rework costs once a feature or story has been accepted as “done.”
It helps create a culture of collaboration and increases communication.
It provides clear contact between the team and the customer to limit the risk of misunderstanding and assumptions that can lead to conflicts.
It allows the organization, especially engineering teams, to understand what is expected of them once they make commitments at the beginning of the sprint.
It increases the efficiency of the entire process because it provides clear criteria about what needs to be completed to finish an artifact, such as a feature, sprint, or user story.
On What Levels Can We Use It?
Definition of Done is mostly associated with user stories but can also be used in other areas such as Sprints and features.
Definition of Done for a feature
The following criteria may determine the Definition of Done for a feature:
The customer approves all-important stories relevant to this feature.
There is a full, stable working version ready for release.
All bugs are resolved technically or in an "acceptable" state with the approval of the PO.
Feature documentation is complete, including user manuals, release notes and known issues.
Definition of Done for a Sprint
The Definition of Done for a development Sprint may be determined by the following criteria:
The sprint goal is accomplished.
All user stories are completed and approved.
Release Notes are written and documented.
Automated tests written, executed and passed.
Definition of Done for a user story
The following criteria may determine the Definition of Done for a user story:
All tasks necessary to implement and test the selected story have been identified, estimated and approved by the team.
All bugs associated with the story have been reported and verified.
All coding and testing activities are complete.
Every story added to the sprint backlog is fully understood and approved by the team and has all the elements of a user story, including acceptance criteria, acceptance tests, etc.
The code was integrated into the main branch.