Definition of done is an agile practice of making sure that there is a broad agreement on when a task is completed. This is often implemented as an agreed upon checklist of criteria that can be checked off.
The practice is most often used within agile software development such as Scrum. However, it can with ease be used within a ITIL service desk on definitions of then an incident, problem or change request is done (or resolved if you wish).
There are several benefits of defining definition of done criteria. The main benefit is that it minimizes the risk of misunderstandings and conflict between technicians if and when a task is completed. It also lessens the amount of rework needed to fix something.
It is crucial to gain acceptance and knowledge of the criteria when implemented. My suggestion is to print the agreed upon criteria and set them on the team wall(s) or similar.
How to define the definition of done?
Ideally the teams using the definitions sets the criteria. However, most of the time external input is needed from customers or processes. If there are multiple teams sharing the same process, the definition most likely must harmonize between the teams.
An example of how definition of done for problems (ITIL):
- Root cause identified
- Action list created
- Documentation updated
- Verified with end user
Issues with definition of done
There are of course some pitfalls associated with using definition of done. The biggest risk in my experience is that technicians can fixate too much on the list. This can lead to problems that arise from following the list too strict. On the other hand, if the definition of done is too informal everyone may have a personal interpretation on what the definitions are.
It is crucial that the definition of done criteria are measurable. If not it’s very hard to have an agreed understanding of the criteria. Furthermore, if they are measurable, you are able to measure the rate of done on a set of tasks. For example, a criterion saying “Customer satisfied” without defining on how to know when a customer is satisfied is a highly vague definition and open for interpretation.
You could argue that the definition of done should (or must) be a part of the ITIL process it refers to. This is in my experience not always the case and the definition of done is a great complement to resolve this. If you have all this in your processes and support for it in your trouble ticketing system, then perhaps this practice is not for you.
Getting started with a Definition of Done (DoD) – https://nkdagility.com/getting-started-definition-done-dod/