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...

Photo by Glenn Carstens-Peters on Unsplash

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 leftA fragile code base that makes it difficult, expensive, or dangerous to make changesInconsistent approach to development practicesLack of role clarityNon-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.

---

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?

Yes.

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

Making Ready

3-5 Acceptance criteria definedDefined automated testsSuccessfully triaged and passed INVESTEstimated appropriately using 3 Amigos

Developing

Appropriate unit tests are written and passingAutomated tests passing (QA Product)Acceptance criteria passedAppropriate refactoring completedPeer reviewedDocumentation updatedDeployable artifact producedValidated in a production-like environmentFunctionally hidden behind a toggle

Testing

Exploratory testing passedProduct Owner checkedUX validated

Deploying

Deployed to customerProduction 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?

The post Writing a Definition of Done appeared first on Sean Robinson Consulting.

---

View Entire Post