In software, there's nothing closer to a magical, silver bullet than a written Definition of Done (DoD).  A Definition of Done is typically created by each team and it describes all the items that have to be completed in order to call something Done.  Why do you need a DoD?  Well, have you ever had this conversation before?

Developer: I completed the work on Feature XYZ.

Manager: So, it's done?

Developer: Yup.  It's done.

Manager: "Done"...or "Done Done"?

Developer: Uhhhh...it's Done.

Now if you've heard that conversation before (or maybe you've participated in that conversation before), you know that there's a pretty huge difference between "Done" and "Done Done".   Between "Done" and "Done Done" is a whole lot of work and basically it means that when you say "Done" you really mean something else.  Translation: "it's not done."  For example, in the sample conversation, "Done" for the developer probably means that it compiles and it's been checked-in to version control.  To the manager in that conversation, "Done" means that it's ready to be deployed to production and used by actual users.  The reason the manager might ask "Done vs. Done Done" is that he or she has been burned in the past by misunderstandings about what "done" actually means.

This is where a written Definition of Done (DoD) comes in.  If you're on a Scrum team, your DoD describes everything that must be completed before the Product Owner can consider a Product Backlog Item (PBI) is done.  While that code might compile and might even work, any step on the DoD that hasn't been performed yet is potential technical debt.  Technical debt refers to all those little tiny pieces of not entirely done 'stuff' that's scattered around your codebase.  A written DoD helps everyone communicate with 100% clarity about the status of a PBI and removes the ambiguity about when/how the entire Scrum Team (the Product Owner, Scrum Master, and the Development Team) decides that a PBI is done.  No more done vs. done done.

It's More Than Just Compiled Code

The problem in the "Done vs. Done Done" conversation is that there's a difference of opinion about what done means.  Now, since we work in what is commonly referred to as the "Software Development Industry", people tend to think of 'done' in terms of whether the code is written.  This actually has a lot to do with the problem because I think that our industry is misnamed.  It really should be called the "Software Delivery Industry".  If you think of it as the Software Delivery Industry, the definition of what Done means suddenly gets a lot more expansive because there's a whole lot more to delivering software than just writing the code.

When you and your team sit down to create your written DoD, you're going to discuss *everything* that it takes to get the software (or PBIs) to Done.  That definition is going to have *A LOT* more on it than just the code is written.

BTW, you're also going to stop making a distinction between "Done" and "Done Done".  From this point forward, you and your team will consider "Done" as a boolean/binary condition: two states -- Done or Not Done.

A Sample Definition of Done (DoD)

Here's a sample DoD.  I use this with my clients and students as a starting point.  There are almost always project-specific items that a team will want to add to their DoD so feel free to customize it.  My sample DoD has two sections -- Developer/Coder and Testing, Deployment, & Operations (DevOps).  While there are two sections, make no mistake, this is *ONE* and only one Definition of Done.  To the team, "Done" is going to mean one thing: all the items on the entire list have been taken care of.

Part A: Developer / Coder

• Code is written with unit tests
• Unit tests have a minimum of 75% code coverage
• Code has been merged to Main/Trunk
• Code compiles and unit tests pass when integrated and run as part of an automated build
• Database schema objects are under source control
• Database upgrade script for the PBI is under source control
• Code has been reviewed by someone other than the original author

Part B: Testing, Deployment, Ops

• Written QA test plan
• Tested using the QA test plan by someone other than the original author of the code
• Deployed and tested in a Staging environment
• Automated UI tests are written and the tests pass
• No Severity 1 or Severity 2 bugs (aka. no "show stopper" bugs)
• Reviewed by the Product Owner
• Passes acceptance criteria for the Product Backlog Item (PBI)
• Known production deployment and rollback plan
• Deployment plan has been reviewed by Operations
• Database changes have been reviewed by the DBA or DBAs
• Load tested
• Deployed to Production

Summary

As you can probably see, there's a whole lot more to a Definition of Done than merely having the code written.  This not only helps you to communicate effectively about Done but it also helps everyone to have a solid understanding of how much work everything takes.  One of the fantastic things about this is that it helps you to get better at estimation because, when you estimate, you'll refer back to your DoD and it will be much clearer to everyone how much work something actually takes to get to Done.  That DoD also helps a lot when your (for example) CTO come in to your office asking for a "quick, two-second fix" because you'll be able to point out that it might be a quick coding fix but that there's a lot of other stuff that has to happen before we can say something is done.

Anyway, I hope this helps.

-Ben

-- Technical debt got you down?  Is your Scrum Team having a hard time figuring out what Done means?  Do you want to try to automate your Definition of Done?  We can help.  Drop us a line at info@benday.com.