Whether you are working on a small task or a large project, do you and your team have a clear understanding of what it takes to complete a piece of work? The Scrum method of software development calls this Definition of Done and touts this as a critical practice for high-performing teams. While I have used an implicit, informal definition of done for coding for years, recently I have been enlightened as to the value of having an explicit, written definition that the team agrees to and understands.
Why is having a definition of done so valuable? I have grouped the benefits it provides into the following categories:
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:
|Definition of Done||% of Items Relating to Quality|
|http://www.agile-software-development.com/2007/07/definition-of-done-10-point-checklist.html||50% (5 / 10)|
|http://www.scrumalliance.org/articles/37-are-we-there-yet||46% (6 / 13)|
|http://www.scrumalliance.org/articles/107-how-do-we-know-when-we-are-done||60% (3 / 5)|
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.
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.
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.
If you find this article helpful, please make a donation.