What Is Done?

The Definition of Done is an important part of the software development process. I’ve talked about being Done Done and Telling You What I Want before. I’ve also talked about the difference between Stories and Tasks. All of those things tell you about the importance of knowing what done means. There’s also some guidance in there on how to define done.

What those posts don’t do though, is point out any of the potential hazards along the way. Like most other sets of directions, they provide guidance on what to do, but they don’t tell you much about how to recognize when you’re off course. How to recognize the situations where your definition of done is actually causing more problems than it solves.

The first, and arguably, the most important, is being too rigid. You have your acceptance criteria and damn it, you either meet them or you don’t. You said there would be 95% line coverage with unit tests, but there’s only 94.87% coverage. You failed. Or you said there would be a P95 response time of less than 100ms, but P95 is 110 ms. Sorry, you tried hard, but you failed. That’s pretty demotivating, and no-one wants that, so instead of admitting to failure, you ignore the definition, declare victory, and move on. Everyone feels good. But after a few such occurrences, the definition of done becomes unimportant. Since everyone knows you’re just going to move on anyway, why bother doing what you said?

Being too rigid in the definition, then ignoring whether you met the definition or not quickly leads to the definition of done being irrelevant. The trick is to make the definition of done comprehensive enough that you’re always adding value, but not so strict that 50+% of the time you end up missing it. Instead leave some room in the definition of done so that it’s almost always achievable.

Which leads right to the second problem. Failing to inspect and adapt. Whether you call your process Scrum, Agile, XP, Kanban, BDUF, or something else, if you’re not paying attention to what’s really happening, you’re not going to end up where you want to be. Not meeting a definition of done by the specified date is a problem, but a bigger problem is to just accept that it happened, and will continue to happen, and not try and make things better. Every failure to meet a date is not a problem, it’s an opportunity.

Acknowledge the miss, then look at your process and your definition of done and make changes. As I mentioned above, you can make the definition less rigid. Instead of saying 95% coverage, say that coverage will be > 95% or the coverage at the beginning, whichever is lower. Now, your goal is not to suddenly meet some arbitrary coverage number, but to keep getting better until you meet the threshold you’ve defined you need to maintain.

Along the same lines, and worth a whole post on it’s own in the future, is that using a standard definition of done is a problem. It might be too rigid. It might be too lax. If it’s standardized and shared, it’s almost certainly out of context. Even if it’s a “best practice”, the label of best practice comes from someone else, and might not (probably doesn’t?) apply in this specific case.

So by all means, have a definition of done. Make sure it fits your team and context. Define it so that it’s achievable. Achieve it whenever you can. When you can’t, fess up to the miss. And always, always, always, take the time to look back and learn how to make your definition of done better.