In too many activities, a definition of “done” seems to be missing.
I don’t know about you, but when I have too many unfinished things on my plate – my performance suffers.
Every unfinished activity has a cognitive load attached.
If something is not “done,” – it tends to hang out in my head and simmer there.
Too many of these things and it gets overwhelming.
One of the environmental characteristics of the flow state is clarity of goals.
Goals have many levels. At the basic day-to-day, what are you trying to accomplish?
What does a completed state look like?
If you don’t know, or if everyone involved has a different definition, it’s going to be tough to know how you are doing and next to impossible to determine progress.
That activity, without a definition of done, becomes a resource sink for both money and time.
Furthermore, it makes it difficult to move on to other opportunities.
Your resources will continue to be tied up in the never-ending project.
The definition of “done” should be explicitly spelled out and agreed to by all parties.
What are the criteria that need to be met to consider something complete?
These criteria can include deliverables and quality standards for those deliverables.
Example – The project team has determined that the best approach to communicate to the end-user, with the resources they have available, is written end-user training documentation.
The project team decides that the end-user training document is complete when:
- All written content identified for development is 100% complete with no grammatical or spelling errors
- All graphics have been completed and laid out in the manual
- The table of contents is complete and accurate
- 95% of the target audience easily understands the document and can follow the instructions without further guidance.
- The document is ready for conversion to PDF and distribution via email to the end-user.
The Agile Alliance recommends posting that definition someplace visible to keep everyone on track.
This activity helps maintain clarity of goals. You know what you are working towards and you know how close you are.
These definitions can (and should) be created at multiple levels. You can create them per user story and/or per deliverable and create an over-arching one for the project.
I have encountered significant resistance in creating a concrete definition of “done.”
I’ve heard fears around the lack of flexibility, as well as the fears around the accountability demanded when you have stated explicitly what you are going to do. I’m sorry, but accountability is necessary to get anything done.
However, I do think the fears around the “lack of flexibility” are unfounded.
The flex remains in how you get from where you are at to “done.”
To use the example I mentioned above – the definition of done may be a training document with no spelling errors and understandable by 95% of your target audience, but the document itself can be one page or many pages, leverage graphics in interesting ways, be serious or fun. As long as the document meets the definition of “done” for that deliverable and helps the greater project to deliver the promised value, you are golden.
You can use the concept of “definition of done” for projects (which should have one anyway – traditionally managed projects call this scope) and for personal activities (ie – when is my part “done” such that I don’t have to think about it anymore).
All I ask is that you develop the discipline of defining “done” and finishing activities.
I’ve found over the years that those disciplines go a long way towards reducing overwhelm.