In software development, having a Definition of Done ensures that transparency and quality of the completed work fit the purpose of the product and the overall goal. A good DoD gives us the feeling that the potentially deployable software increment meets the standards in terms of quality and usability.
How to create a definition of done for your feature, project, or task in 5 steps
- Decide on your definition of done as a team
- Create a checklist template for your definition of done
- Don’t obsess over the list of criteria
- Make sure each individual task has its own specific acceptance criteria
- Update DoD when needed
So how do you come up with a Definition of Done that works for everyone? In this guide, we’re going to cover exactly what a DoD is (and isn’t) and how you can develop, track, and update them as a team.
What is a Definition of Done (DoD)?
According to the Scrum Guide, you use the definition of done to assess when work on the product Increment is complete. It ensures members of the Scrum Team have a shared understanding of what it means for work to be complete.
So the definition of done makes transparent your team’s shared understanding of what needs to happen for any piece of work to be completed to a useable standard. Think of it as a checklist that defines what’s needed for an Increment to be releasable at the end of a Sprint.
1. Decide on your definition of done as a team
Who defines “done” for your user story/feature/project?
While defining “done” should include input from the product team, quality control, and relevant stakeholders, it’s ultimately up to the technical team to decide what it means.
However, this has to be a collaborative process. Without input from other teams you won’t get the support you need to ship a feature. You’ll also be stuck dealing with stakeholders who have different expectations or are confused as to why a feature hasn’t shipped.
To help this along, it’s essential that your definition of done is available to everyone and that there is transparency around why those are the requirements you chose. This way, everyone knows why a release or feature is held up and what needs to be done to move it forward.
2. Create a checklist template
Definition of Done is a set of criteria that the requirement must meet in order to be considered complete. This is sort of a checklist with some elements to be checked before indicating the Increment as done. Ensure that these rules apply to every task or issue within the sprint. Many teams often focus only on the criteria for small features or issues while forgetting the larger definition of done. A good idea is to embed the DoD into the workflow.
3. Don’t obsess over the list of criteria
When defining the completion criteria, make sure that they are clear and “sharp” to all participants in the process. There is nothing worse than “Requirement will be complete after all tasks in Jira have been completed” or “Unit testing should cover enough classes”.
A good rule of thumb is to think of your definition of done as the minimum work required to meet your agreed-upon quality level.
4. Make sure each task has its own specific acceptance criteria
To successfully complete your sprint you need acceptance criteria and a well-defined Definition of Done. The best thing to do is to assign them to each individual task to avoid any confusion or neglect. Make sure each issue includes relevant information – it makes it easier for the team to figure out what they need to be working on and tick off the right acceptance criteria as the development progresses.
5. Update the Definition of Done when needed
The definition of Done grows with the product. New criteria probably will be added to it, and the existing ones will be more strict. That is why its shape is regularly inspected and adapted, like all Scrum elements; a good time to change the DoD is the Sprint Retrospective – then the new Definition of Done is valid from the beginning of a new Sprint.
In the end, a Definition of Done is all about trust
There’s one final reason you should care about a definition of done: It builds trust across your team and your entire organization. A shared, open, and honest vision of what quality software looks like puts everyone on the same page.
