My Definition of Done

On his blog, Steve Rowe shares a story of an employee who claims to be done their work, but by Steve’s standards is not. Steve puts this down to a difference in opinion of the word ‘done’.

“The problem stems from the fact that we rarely define the word. It is assumed that everyone shares a definition but it is rarely true. Is a feature done when it compiles? When it is checked in? When it can run successfully? When it shows up in a particular build? All of these are possible interpretations of the same phrase.”

Now, I completely understand the issue that Steve has had here, but I don’t agree that it simply comes down to a different definition of the word done. Done is done. When all of the requirements for the task are complete, the task is done.

Clear and purposeful documentation of the application that is to be built, outlining features and requirements will help show the developers what work needs to be completed prior to a task being done.

Define the task

The ultimate responsibility falls on the manager. A manager should be outlining their requirements for a task, or project, that the developer can follow.

Ideally this wouldn’t be a unique, per task requirement, but rather a general procedure that defines each task. This helps automate most of the processes and would then only require the manager if there is a unique or new situation.

My point is this: as long as the task is clearly defined it is easy for anyone to know when they are done. Focus on proper task definition and your staff will have a much easier time knowing what they have to do, and executing it. And you’ll have a better idea of where your projects are at.