The Concept of Done

January 12, 2010


While I’m not overly keen on documentation for the sake of documentation, an often overlooked and useful artifact is a team agreement of what constitutes a piece of work being completed.

When I say completed what exactly do I mean ? Well every project will have its own specific criteria, but what it signifies is the intent that there is no more work remaining on a story. Of course, this can only be based on the understanding at the time, but once a story reaches the ‘Done’ state, then any future work on it should be considered as a separate story (or bug fix, if you track them separately). Done can also be applied at different levels, such as iteration or release, but I find it most useful at a story level.

So why is this concept important ? I find that at a process level, it provides a checklist that keeps your project housekeeping under control and reminds people to complete all the tasks. While this is certainly convenient, what I like about a “Done” definition is that it encourages you to complete one piece of work before moving on to the next. For sizing and scoping a story it also acts as an important guide to prevent stories that are too large or really need to be multiple stories. If you like the TDD approach, you could think of it as an upfront, perhaps slightly crude, test for your story.

The whole team should be in agreement about what should and shouldn’t be included. While you can force your ideas on others it tends to demotivate those opposing it. An agile process is constantly being refactored and tweaked as it’s reviewed and evaluated based on how well it’s fitting the team. Given this state of potential change, a wiki is a great place to store your ‘Done’ definition and makes it clear that it is easy to change.

An example of a “Done” definition could be the list shown below. This is by no means an exhaustive list or even appropriate to all projects, but it gives you a taste of what one might contain:

  • All code checked into source control
  • All unit tests passing (and that you’ve not slowed the test suite down excessively)
  • All Fitnesse & integration tests passing
  • Any follow-on stories created
  • Any associated documentation updated/verified (i.e. manuals, etc.)
  • Story/Issue tracking system updated

Some people might be expecting code reviews and design sessions being signed off, and if that’s how you work then maybe you should include that. I’m a big fan of pairing, doing only a little upfront design, and letting the detailed design be emergent, so I don’t include these items. If you were defining a definition for a larger piece of work like an iteration or release, then perhaps they might be more appropriate.

Advertisements