I use two guiding principles as the basis for constructing my definition.

1. Potentially releasable: Ideally the software can be released (or shipped) once it is done. I've seen many people, particularly in the context of Scrum, use the similar term "potentially shippable".
2. I would trust my life to my code: I just wrote an entire article on this titled Would You Trust Your Life To Your Code?

These principles are deliberately idealistic in order to set high expectations and motivate continuous improvement when I fall short of reaching them.

Different definitions of done can be created based on different levels or scopes. The two primary scopes are:

1. Done for a feature / user story.
2. Done for a release.

For this article I am using my definition of done for developing a feature (user story).

My definition of done is essentially a checklist with items grouped into categories. The lists of items and categories are not meant to dictate the process by which these items are done or the chronological order. For example, automated unit testing is listed in a separate category from coding but it is typically done at the same time or before-hand, if doing test-driven development.

Without further ado, here is my definition of done.

Coding

1. Code meets functional requirements.
2. Code meets non-functional requirements. Typical ones include:
   • Performance (capacity, scalability)
   • Usability
   • Security
   • Maintainability
3. Code is deployment-ready. This means environment-specific settings are extracted from the code base. A past article I wrote on designing for deployability provides more context on this.
4. Code is checked into version control.
5. Code complies with coding & architectural standards.
6. Code has been cleaned up. The goal is to ensure the code is easily readable and has a good design. In the past I have used the terms polishing code and refactoring to describe this. Robert C. Martin's book Clean Code: A Handbook of Agile Software Craftsmanship provides the best explanation of this that I have seen. Achieving this goes a long way towards meeting the maintainability requirement.
7. All TODO-style comments in the code have been addressed and removed.

Static Code Analysis

1. Code has been analyzed by static code analysis tools. The two primary tools I use for Java development are the Eclipse compiler and FindBugs. Other Java tools include PMD, Checkstyle, and Architecture Rules.
2. All errors and warnings found by the tools have either been corrected or have been suppressed with a comment indicating the reason for suppression.

Testing

1. Automated unit tests are written. The tests should be high quality (e.g. not brittle).
2. Automated integration tests are written that verify interactions with external systems such as the application database or third-party application / web services.
3. Code coverage achieved by the automated tests is measured and sufficient coverage is achieved. I use Cobertura for measuring code coverage. I do not like using only a numeric percentage coverage target as the sole definition of sufficient coverage, because this can encourage people to write poor-quality tests that merely execute the code rather than verify its correct behavior in order to meet the target. My true definition of sufficient coverage is that the tests execute and verify all code that could reasonably be incorrect. Having said this, I generally aim for at least 80% line (statement) coverage overall, and often achieve 90%+ coverage for individual classes. I am still debating what a reasonable target is for branch (conditional) coverage . I currently aim for at least 50% overall, but I have the feeling that a target of 75% would be better.
4. Functional testing by someone other than the developer has been done. Ideally this testing will be done by the customer, involve exercising the complete feature being coded in the way that users would use it, and be fully automated. More frequently I have seen this testing done manually (especially for user interfaces) by business analysts or testers who act as proxies for the customer. The key idea is to have someone other than the developer do testing to validate the assumptions and interpretations made (often implicitly) by the developer.

   I use the vague term "functional testing" rather than the more common terms "system testing" or "user acceptance testing" because projects can differ dramatically in what is done for system or user acceptance testing. If acceptance testing is done in a waterfall fashion as a separate phase near the end of the project then it cannot be part of the definition of done for a feature (but it is still part of the definition of done for the release). So I use the term "functional testing" to indicate this potential differentiation. Ideally, based on lean principles, all testing including system and user acceptance testing should be done as part of the work on a feature and not artificially delayed till later.

Reviewed

1. Design / approach has been reviewed by the technical lead / architect.
2. Detailed peer review / inspection has been done. If pair programming is being used then the peer review is automatically done at the same time as the coding. Otherwise, the reviewer should focus on issues that are less likely to be found by the static code analysis or automated testing. This can include items such as security holes, concurrency issues, and correctly meeting requirements.
3. Issues identified by reviewers have been resolved to the reviewer's satisfaction.

Other

1. Required documentation has been updated. This may include online help, user manual, or operations manual.
2. Build and deployment scripts and related configuration files have been updated.
3. No known defects are outstanding unless the customer has agreed to defer them, in which case they should be logged.
4. No known tasks related to the feature are outstanding.

That concludes my definition of done. I would appreciate hearing about what you use for a definition of done. In particular, if there is anything you think should be added or removed from my definition please let me know via a comment below.

Why is having a definition of done so valuable? I have grouped the benefits it provides into the following categories:

Higher Quality

Definitions of done should typically focus less on the activities people normally do and focus more on the activities that tend to be neglected or forgotten. In software development this means specifying activities that ensure the quality of the code being produced, rather than the actual act of coding. Quality often means much more than just few defects: it can also mean readable code, a clean design, or achieving any number of other non-functional requirements such as security, performance, and scalability. A definition of done that includes quality aspects serves, therefore, as both a reminder of the importance of quality in the day-to-day work and as a set of expectations regarding the level of quality to strive for.

Out of curiosity I decided to check out a number of publicly available definitions of done and count the percentage of items that clearly related to quality. Here are the results:

Standardization

A written, clearly-specified definition of done is essentially a standard. Standards provide many benefits when properly applied using a lean (pragmatic) mindset rather than a bureaucratic mindset. The proper mindset can be summarized using the following dichotomy: a standard represents the best way we know today of doing some activity within some context, yet each day we search for a better way so as to improve the standard. As implied by this summary, standards help form the foundation for future improvements. This is because following standards brings consistency which makes it easier to analyze the results of the work being done, determine the root cause of problems, and identify how to improve. For more on how standards help improvement efforts see my article on a framework for continuous improvement.

Standards have a number of other benefits. Checklists can be created from the standards for use by both the people doing the work (as a reminder of what to do), and by the people verifying the work (as a quality assurance check). Standards are helpful in training new team members. Having documented standards can also be helpful for achieving certain certifications like ISO or passing regulatory requirements such as Sarbanes-Oxley.

Most definitions of done do not mandate the specific step-by-step procedures to follow, but rather set expectations regarding the final product produced. To illustrate, a definition of done for coding features will likely mandate that certain kinds of testing be done (automated unit testing, functional testing, etc.), but will typically not mandate the sequence in which the testing and coding activities are done. (So unit tests could be written before the code as per test-driven development, or they could be written afterward - either approach will satisfy the definition of done.) Team may choose to standardize which procedures are used, but this is typically kept separate from a definition of done.

More Accurate Estimates

Having a definition of done helps estimation accuracy in two ways. First, it serves as a checklist of all the steps required to complete an activity that can likewise be used to estimate the effort remaining. When estimating the work left on a feature, for example, a definition of done can help ensure that time is estimated not just for the coding, but also for reviewing and testing.

Second, a definition of done makes it easier to track the actual progress, since activities reported as done are more likely (but not guaranteed, unfortunately) to actually be done. This means there will be less surprises in terms of additional work required for previously 'completed' assignments. These surprises, of course, significantly reduce estimation accuracy, so the more they can be eliminated the better the estimates.

Better Teamwork

The previous benefits apply when you are working on your own, but software development is more commonly a team activity. And in addition to these prior benefits, having a definition of done will make your team more effective. Many of the challenges of working in terms such as achieving unity of purpose, clear communication, and coordination of effort, benefit from having a definition of done. When team members are communicating about the work that has been and needs to be done, having a clear definition of done helps avoid misunderstandings. The definition functions, in essence, as a communications technique for ensuring that when team members use the word "done" they all mean the same thing.

For examples of what happens without a clear definition see this story of a team of five having three different viewpoints regarding done and this story of someone reporting a status of 'finished' that really wasn't.

Concluding Thoughts

This article has mostly discussed definition of done in the context of software development and specifically coding, but the concept is much more broadly applicable both within I.T. and beyond. Staying within I.T. I can see the benefits of having definitions of done for activities such as incident resolution by support staff, product high-level requirements definition, and pursuing sales. So I challenge you to look for opportunities to use a definition of done to help achieve superior performance.