A definition of done is one of the cheapest and most effective ways in which you can start tackling IT issues. It can improve quality, transparency, accountability, alignment, and even predictability. All at the cost of a conversation and some documentation.
There’s plenty of material on what a definition of done looks like and why you might want one, but not much on how to go about constructing your own. This is my attempt to fill that gap.
Why would you want a definition of done?
Before digging into the mechanics, let’s explore why you should actually care in the first place. You might want to continue this article if you’re experiencing any of the following:
- Late bug identification, either inside the system or once it’s left
- A fragile code base that makes it difficult, expensive, or dangerous to make changes
- Inconsistent approach to development practices
- Lack of role clarity
- Non-uniform definitions of what it means for something to be ‘done’, often resulting in multiple conflated processes
So what is it?
A definition of done is effectively a checklist, a list of activities and outcomes that must be achieved before we will consider a piece of value work done. And if you’re now asking what done means, that’s the point.
If you can put a tick next to every item on your definition of done then that should mean that you can release that value to a customer. If the sum of those items consistently results in high-quality, valuable, robust software, then that’s a good indication that you have a quality DoD.
Where did it come from?
Bill Wake kicked off this process by highlighting inconsistencies in the word ‘done’. Interestingly, this is still a common occurrence 20 years later. Done or dev-done? Done or done-done?
Scrum quickly incorporated discussions of done, followed by documented done processes shortly after. It’s remained a core and one of the most valuable parts of the Scrum framework ever since.
What format should a definition of done take?
I’m less prescriptive with this. In a shared physical environment you can easily print it out and stick it on the wall next to your other information radiators. In a virtual context you will need to use a shared digital medium such as a wiki. It’s actually not a bad idea to write it up on a wiki even if you’re in person.
How do I write one?
When writing a definition of done, I actually take my inspiration from the STATIK method. Rather than attempt to write up a complete document from scratch, I would suggest rolling up the various status policies into a single document.
In the Kanban implementation method described by STATIK, one would identify policies for each status in the system. The sum of those policies should provide your ideally balanced DoD. Let’s unpack this a little.
A Kanban board is a physical or virtual representation of the system that work will flow through to get to the customer. That system describes each activity or function that the work touches. This usually starts with a customer need and ends with that need being satisfied.
In IT, we have a number of transitional states such as analysis, development, testing, and acceptance. We represent work using a small card that describes the customer’s need and any relevant details to its completion. This is called a kanban card. We move the kanban card along the statuses on the board as we complete the work for that status.
Each column has a maximum number of cards that can be present there. This is called the WIP, (Work in Progress), limit.
At the top of each column, which represents a single status, there is a card that lists the policy for that status. This policy is made up of a number of list items. Each list item is an outcome that must be achieved before the work can ‘pass‘ the current status.
What this means in practice is that a well designed Kanban system will implicitly produce a well-defined definition of done.
Not only will you have appropriate policy gates to ensure quality as early as possible, but you will also be able to accumulate each policy into a single document. This document represents all of the required outcomes that need to be achieved before we can release value.
What’s out of scope for a definition of done?
A definition of done is not a detailed description of your SDLC
A definition of done is not a comprehensive list of all aspects of the software development lifecycle. If you have some specific unit test requirements, such as style or tooling, then link out to a specific strategy document. The policies are written on index cards for a reason, keep them concise and high level. They describe the what but not the how. This is a fine line to walk, it’s about balance and there isn’t a right answer.
A definition of done is not a list of acceptance criteria
A definition of done should also stay away from functionality. They are not substitutes for acceptance criteria. I’m not even sure how this would work, but I’ve seen DoD guides confusing the two. Acceptance criteria describe the outcomes that a specific piece of customer value should achieve, along with any relevant non-functional criteria. The definition of done details the activities we will perform in the execution of our work in order to achieve an appropriate degree of quality and consistency. It is not necessary to have acceptance criteria for passing the definition of done, it’s a given.
Do we apply them at the Story, Epic, or Release level?
It is perfectly valid to have variations of your definition of done for different constructs. However, I would argue that there is value in uniformity. If you can produce a single DoD that represents all constructs then you can link out to the specific implementation as required. This provides a common grammar and understanding across the organisation.
Poor choices for a definition of done
|Bad Example||Better||Why it’s better|
|Unit test coverage > 85%||Unit tests passing||Code coverage isn’t great anyway. We should generalise and link out to our strategy for specifics. It’s more concise and allows for greater uniformity across applicable structures.|
|Non-functional and functional acceptance criteria passing||Acceptance criteria all passing||Non-functionals are acceptance criteria, we don’t need to differentiate.|
|No bugs associated with the feature||No blocking bugs associated with this feature||Potentially controversial, but the team should be able to make a mature decision about whether to release software that contains minor defects. The opportunity cost may simply be too high. It’s important to collaboratively define and document where this line is. A line in your software strategy that prevents P1 or P2 bugs being deployed if known is appropriate, for instance.|
|Ready to deploy||Deployed and in active use||We’re in the business of customer value, the creation of IT product to do so is our chosen vehicle. Customers don’t care if it’s dev-done.|
An example Definition of Done
It’s obviously very difficult to write a definition of done that will be applicable anywhere else, let alone everywhere else. But here is an example of what it might look like. I’ve included more detail in some items as I wouldn’t typically have a separate document for that process.
Definition of Done
- 3-5 Acceptance criteria defined
- Defined automated tests
- Successfully triaged and passed INVEST
- Estimated appropriately using 3 Amigos
- Appropriate unit tests are written and passing
- Automated tests passing (QA Product)
- Acceptance criteria passed
- Appropriate refactoring completed
- Peer reviewed
- Documentation updated
- Deployable artifact produced
- Validated in a production-like environment
- Functionally hidden behind a toggle
- Exploratory testing passed
- Product Owner checked
- UX validated
- Deployed to customer
- Production metrics within acceptable range
Of course, this is just a quick example of what it might look like. No doubt you’ll have different ideas, perhaps radically so. What matters is that whatever you use, it’s working for you and the customer. A definition of done should remove the guesswork and be an enabler of value flow instead of a bureaucratic blocker.
As your system changes, so should your definition of done. Make sure you take time to keep it alive, take 2 minutes during your retrospectives to reflect on whether you need to adapt.
I’d be interested in hearing about your definitions. What items are on yours? Are you happy with it? How do you go about deciding if a line item is good or bad?