Project management can be a daunting job. In my line of work, software, it is not uncommon for project tasks to have a vague title and a description that is either sparse or entirely empty. The result is often confusion around the intent of the issue which leads to missed milestones and inefficiency. In order to communicate your project goals effectively, every project task should have at a minimum: a title, description, and a definition of done.
I learned about this technique many years ago from a very talented project manager, andy cleff. The definition of done defines what is required to close a task. One important caveat is the definition of done must be actionable. It is also important to be as detailed as possible. Think about crafting your task for someone else to own, even if you are the owner. If you are forced to context switch to something else, future you will be happy to have the details, and the definition of done will clearly identify what is required to close the task.
A trivial example is a task with the title “Fix service”. Ok…fix what? What service? While I realize “Fix service” might be perceived as an embellished task title, I have seen tasks defined this way in a professional setting. The person who created this issue was likely in a rush and intended to fill in the details later…probably not going to happen. Changing the title to “Fix pagination on the customer shopping list page” adds more detail and context, so we can start to understand what is being asked. Next, we will add a description that includes:
- What the problem is.
- Any relevant links to code or observability tools.
- The environment(s) this problem exists in.
- How to reproduce the problem.
Finally, we will add our definition of done. Consider now what actionable steps are required to call this task done. Creating a definition of done can be as simple as a single line: “Paginated lists should only display 10 items at a time”. Often I will make my definition of done a list with a title that clearly states “Definition of Done” or “DoD”.
We now have a reasonable title, a description that helps us understand the problem with evidence and context, and a definition of done that states precisely what is needed to close the issue. Knowing the definition of done will now help us in our planning efforts because it is clear what is required, and it will help whoever ends up owning this task because they will know exactly what to do. The final task might look something like this:
Let us briefly revisit the caveat I mentioned earlier of an actionable task. An actionable task is a task that is accomplishable. If I were to state a task as “Reduce errors for service X”, the very hand-wavy use of “errors” makes this entirely non-actionable. Even if we had a list of all our errors, surely there will be more errors in the future. It is imperative that an actionable task is as specific as possible, with respect to scope, in order to have a definitive end. We can accomplish this by doing the following:
- “Reduce” should be quantified. Reduce the error by how much? What is our goal?
- The “error” is clearly identified and not conflated with other errors. Is it error E390?
This will allow us to change “Reduce errors for service X” into “Reduce error code E390 by 10% for service X”. Originally the task was not actionable due to lack of clarity around the definition of done. Now we know the definition of done is clearly stated as reducing E390 by 10%. If this is a complex problem it may lead to opening new tasks, and each of those new tasks should have a reasonable title, a description, and a definition of done.
Adding a definition of done with actionable tasks is a great way to help clarify your project management process, reduce confusion, and increase efficiency. Once understood the real challenge is being consistent and diligent in its application. Also, while the examples I have presented here are with software projects, these techniques and the definition of done can be applied in any industry or personal project.
If folks out there presently use a definition of done or similar, let us know in the comments below. If you do something completely different and it has worked really well for you and your team, share your insights in the comments below. I am also curious to hear from others who might do something similar outside of software. Thanks for reading!