Using the Definition of Done to Promote Continuous Improvement

The definition of done is much more than just a checklist or an agreement with your product owner on completeness—it can be a mechanism for determining where your product increment can be more complete by the end of your sprint.

Consider the concept of “done-done.” Done-done is a way to differentiate an increment that is complete yet not tested or not potentially releasable. The second done of done-done means the increment is releasable. Done-done is often a crutch.

That said, sometimes it is not possible to create a product that can be shipped every sprint. Think about medical devices that need to be tested in patients, highly regulated software that must be audited, and complex software that cannot be absorbed by customers in short sprints. These types of software are problematic in that the economics don’t allow a releasable product every sprint.

What we need is not just a definition of done; we need a mechanism to analyze our process and ensure that we are coming as close to shippable as possible. We need to force ourselves to complete more process steps and increment artifacts sooner so that our increment is as close to potentially shippable as our environment and economics allow. The definition of done could be used as a mechanism not just to describe completeness, but also to drive conversations that challenge us to move closer and closer to shippable every sprint.

A good way to spur this conversation is to use a four-quadrant definition of done. Draw four quadrants on a piece of paper and label them as in Figure 1. This will be your “definition of done” discussion board.

Each quadrant relates to a state within your sprint process. Items in quadrant 1 are always done when the story is complete, items in quadrant 2 are always done when the sprint is complete, items in quadrant 3 must be complete before a release is complete, and items in quadrant 4 must be done for routine operational maintenance. This discussion board is not to be used as gates for phases (e.g., lengthening a sprint until the items in quadrant 2 are complete, which is a terrible idea).

Now, without judgment, start drawing out what you currently do to get the increment ready. Do you complete all the tasks in the story before deeming a story done? Write tasks completed in quadrant 1. How about unit testing? Of course, so let’s write unit testing in quadrant 1. You can write code review in quadrant 2 if you do it at the end of the sprint. Remember, this is based on the current situation, not on what you feel you should be doing.

Do you check into the branch or trunk? Do you create a code tag? Put them into the right quadrant. Do you perform acceptance testing just before release? Do you do an integration test and a performance test? They would go in quadrant 3. How about a user manual? Release notes? Help text? Installation guide? Release plan? Backout plan? Release schedule for the weekend? All of these things typically go into quadrant 3. Do you have a help desk? Do you have a knowledge base for the help desk? How about a marketing plan for the product? Pricing for the product? Or a sales force that has to be notified? Do you have a support number? Things like this go into quadrant 4.

These quadrants are beginning to reflect where work is being pooled up and completed in relationship to product doneness. You not only have done-done, but done-done-done-done in a very visual format.

Now comes the hard part. Can items in a given quadrant be completed, or at least chipped away at, in a quadrant that is counterclockwise from where it is now? For example, if help text is in quadrant 3, can it be completed in quadrant 2? Can help text at least be created with each story (quadrant 1) and then collated in quadrant 3? Move items or bits of items counterclockwise to challenge yourself to justify why a given activity is in any quadrant other than 1. See Figure 2.

The whole point of this diagram is to list where things are completed now and push yourself to complete them earlier in the process.

To give you an example, one company where I worked used this technique in a somewhat confrontational mode. During the planning of the initial sprint and on subsequent retrospectives, any items listed in a quadrant other than “story complete” had to be justified as to why it couldn’t be moved earlier. At the time, supporting groups found themselves acting defensive for items that were not being completed earlier in the development lifecycle. The sentiment changed from “Can you move this item earlier in the lifecycle?” to “You must move this item earlier in the lifecycle or have a good reason it must stay where it is.” In hindsight this approach was more confrontational than it should have been, but the results were tremendous. Sprints had almost no work that wasn’t done.

Of course, certain things can’t be completed with every story or in every sprint. If you were testing firmware on medical devices implanted in lab rats, you may end up with a lot of dead lab rats. But this discussion can be a pathway to a truly potentially releasable increment at the end of sprint, which in turn reduces the risk of hidden bugs and technical debt.

Challenge yourself and justify why an item can’t be completed, or at the very least started, in an earlier quadrant. This constant striving for continuous improvement will help you see work finished earlier in the lifecycle and come closer to achieving a shippable product every sprint.