The Definition of Done (aka DoD – not Department of Defense) was only recently added as an official commitment/artifact of Scrum in the latest update to The Scrum Guide. However, I have long been a proponent of using a common determination of what “done” looks like. It can vary widely between organizations, departments, and even teams, but it’s crucial that you have a Definition of Done. Let’s talk about why.
What is a “Definition of Done,” anyway?
In an agile context, the Definition of Done defines the boundaries of what it means for a piece of work to be considered complete. It simply provides limits or a checklist of conditions, that must be true or be satisfied for the item to be accepted.
For a software development project, an overarching Definition of Done might contain items like:
- The code has been checked into the proper environment
- A peer review has been performed
- All regression tests passed
- Supporting documentation has been updated
- User acceptance testing has been conducted with no major issues
- No “critical” or “high” severity defects were found
- The Product Owner has accepted the increment
If your product is not software, your DoD might look very different. There’s no one right way or standard for creating your definition, but you should have one.
What if my organization doesn’t have a Definition of Done?
Many organizations don’t have a common Definition of Done that is applicable to all projects or products. There could be many reasons for this, such as:
- Disparate types of products
- Entirely different types of work
- Different technology requirements
- Governmental regulations
- Etc.
If your company doesn’t have a shared Definition of Done, don’t fret – you can create your own definition that applies only to your team. However, if you do have an existing DoD to work with, it may add constraints to your work that you weren’t even aware of.
At what level is a “Definition of Done” defined?
A Definition of Done is typically created at a higher level than the details contained in an individual User Story. If your organization does have a standard DoD, then you may be obligated to use it as a starting point for developing your own. At the highest level, it contains the main requirements that a work product must meet for it to be considered complete. Usually, these high-level specifications are broad, and may not be good enough to call something done at a lower level. So, if you have a high-level version, you will probably end up creating your own definition based on the specific needs of your product or project.
What about “Done Done”?
There’s no such thing as “almost done” or “done done.” I like to quote Yoda when I think about this: “Do or do not, there is no try.” If your product doesn’t check all the boxes of what it means to be done, then you can’t take credit or call it done. If you’re still waiting on “one last thing” to be finished, but you try calling it done, you’re going to catch some major flack. It’s black or white: it’s either done, or it’s not done – there’s no middle ground or partial credit that can be taken.
What formats can a Definition of Done be presented as?
How you represent your Definition of Done is totally up to you. Some people simply create a list, and it’s literally a checklist that someone can go down to make sure everything on the list has been checked. You might have more complicated definitions that include decisions, or phase gates you need to go through. In these cases, you could have more of a matrix or tabular model that you use to compare against. It really doesn’t matter how your DoD is depicted, as long as you have one.
How is Definition of Done different from Acceptance Criteria?
There is often confusion about the difference between the Definition of Done and Acceptance Criteria (A/C). I would argue that A/C are a form of DoD, just at the most granular level possible. The key difference between them is that A/C are specific to a particular User Story and can’t be applied across a broad set of work. Acceptance Criteria can be considered the lowest level of details providing the boundaries of what a done increment looks like. DoD generally acts as an umbrella for most types of projects or products within an organization.
What happens when you don’t have a Definition of Done?
I can’t tell you how many times, as a consultant, I have seen product or project teams that had no Definition of Done at all – not at any level. To me, seeing the lack of a DoD is always alarming. It means that anyone has carte blanche to develop anything they want, without any checks and balances. Developers can go totally off the rails and gold-plate a User Story, adding all sorts of extra and unnecessary functionality. It also means that the story will persist indefinitely because no one can tell when it’s done. People can keep adding to or changing the requirements, and the story never gets closed because it’s constantly in flux.
Final Thoughts
So, what is your experience with having a “Definition of Done”? Do you have one? If not, what problems did it cause? If so, did you inherit it, or create it yourself? Do you distinguish between the different levels of DoD? I’d love to hear any thoughts you have in the comments below!