Imagine the following. You ask your developer if the feature is done? When the developer says “yes, this feature is done”, I challenge you to do the following.  

Look directly at your developer. Hold their gaze for 30-40 seconds. Somewhere near the end of 30 or 40 seconds I guarantee your developer will crack. They will blurt out something like “well, except for testing”. Or “but it only works on my machine”.  

This is why we need a Definition of Done - a shared agreement of what being “done” means to have completed the work, the feature or the user story.

The Definition of Done is a simple explicit checklist of what it means for work to qualify as done. It's a simple list of agreed upon criteria by all parties involved – the development team, QA, the Product Owner, etc.

How important is the Definition of Done?

Now imagine you're at a party. One of your friends starts slurring their speech. You quickly step over to your friend and ask them to look at you and smile. You notice a droop on the right-hand side. You ask them to raise their arms over their heads. You notice that the right arm slowly falls while their right hand stays up in the air. You quickly turn to a friend and ask them to dial 911.  

An hour later you're sitting in the hospital. Your friend is now in good spirits having been taken care of by the hospital staff. It turns out they suffered a stroke earlier that evening during your dinner party.

What just happened? How was action taken so quickly?

The story above is an example of a checklist, called FAST, to identify whether-or-not an individual is potentially suffering from a stroke. FAST is an example of a Definition of Done.

It is powerful because of its simplicity - it's easy to remember, easy to apply, and easy to assess. It's also powerful because it's a binary checklist. It is either all right or all wrong.

For agile delivery teams, the Definition of Done is used to confirm the minimum quality standards agreed upon by the Development Team and the Product Owner. That means for every piece of work the team must meet the criteria outlined in the Definition of Done.

What makes it work? To start, it must be non-negotiable. Here are some essentials:

• Don't skip items
• Ensure each item is met
• Delivery of an item is clear and understood by everyone on the team
• There is no room for ambiguity
• No second-guessing the meaning of each item  

When development teams first start using DoD, they tend to demonstrate partial completion.  For example, during a Sprint Review, the team will demonstrate which items in the checklist have been met (or not met) for a given user story.

Because it’s a binary checklist, don’t do partial completion. That means if the DoD has not been met for a particular story teams should not demonstrate that story during Sprint Review. The team does need to convey that the work is incomplete and cannot be passed over for review to the Product Owner.

Why it is a living document?

The artifact is continually changing.  It is a growing list of quality standards. As the team learns what their quality standards need to be, they update accordingly. As a Product Owner learns the different responsibilities for new feature releases, it updates.

As the Development team adds items to the Definition of Done, they will realize that there is much more to do to create and release a shippable product. The team will need to look for ways to reduce the time it takes to meet each criteria. Typically, this involves automating those practices overtime. Take a moment to review the definition of done used by your teams. We recommend that the definition of done is shared across teams working in the same code base. It is routinely discussed across teams and during retrospectives to ensure that the latest expectations for technical quality are reflected in the definition of done.  

Be careful about how rapidly the definition of done tightens up the technical quality of your product. Each item that you add to the definition of done increases the cost, or the time it takes to complete a piece of work. Therefore, you will typically start with a limited number of items and slowly grow them over time. As you add new items, it is important that original items become habitual within the team's practices, or even better, automated as part of the development process.

It will evolve over time.  

Development Teams are smart. It's not that they consciously ignore the artifact. They are focussed on maximizing the outcome that they deliver by minimizing the amount of work that is needed to achieve that outcome. This is a good trait. The Definition of Done reminds the team that even as they limit the work they do, there is a standard below which they cannot stray.

The Definition of Done places greater emphasis on different items based on the environment and type of work teams encounter.  For example, I worked with a team whose original Definition of Done included “write unit tests”.  Initially, the team felt the item was good enough.  It was only through practice (and experience) that they realized vaguely written is not the same as good enough.  

Here’s how the team’s Definition of Done evolved:

Even as teams rush to complete work during a Sprint, the Definition of Done reminds them of the duties, responsibilities and work that they've committed to.

Anyone who has worked with teams, has tales around their experiences with the Definition of Done. Stories of teams craftily working around criteria. Stories of teams that retake control of their systems by gradually increasing the quality of those systems. Step-by-step, adding unit tests, acceptance criteria, automated check-ins, or automating regression tests.

Each of these steps brings teams closer to a stable system. Build out a safety-net that allows the team to move quicker and take more risks, safe in the knowledge that the system will protect them rather than let them down.

The Definition of Done is powerful.

Take a moment to think about the funniest or most inspiring stories around this topic, and don’t hesitate to share.