During the last Agile SW Development Practices Seminar in Vantaa the participants shared a set of stories about how the switching to the agile development methods proceeded in their companies. A reasonable amount stories included a mention about that without the agreed definition of “done”, nothing was completely done.
Few weeks ago, when starting a new project, our team decided to try figuring out what our ‘done’ means. It was a total surprise to discover that within a small and rather coherent team of five persons we had three different points of view.
Importance of ‘done’
People are different. They have different experiences and perceive the software development projects from the different perspectives. When developer tells that this or that feature is implemented, he often means, that all the functions are implemented and are ready for optimization, refactoring and extensive testing. On the other hand, when customer or manager hears that the feature is implemented, he often expects it to be ready for the release. This inconsistency can lead to the system composed of inconsistent components: half-tested, half-documented, half-optimized and eventually half-ready for the release. That’s why an explicit and concrete definition of “done” is the small, but important checkpoint in the software projects. Pay attention to this issue, talk it over with your boss and your customer. As a result of a rather small effort investment, you’ll have much getter grounds to describe the project state. A typical definition could be as simple as: “‘Done’ means, that the feature is implemented, reviewed, unit tested, but not necessarily documented”.