Scott Schimanski recently added his voice to those talking about the power of a clear definition of "done." Scott points out that there is both business and personal value in a well-defined meaning of "done". The business can count on shipping features that are done, without making any additional investment, while individuals really seem to enjoy the sense of accomplishment that comes with "done."
One of the most powerful aspects of agile development is iterative development.The idea of taking a large development effort and breaking it into distinct smaller efforts. Those efforts are then planned, committed to, worked on and completed. You know the drill. But it’s not just the coding that’s done, but all the work, including testing, documentation, install packages, whatever it would take to make it usable in its final destination.
Ken Schwaber spent a lot of time at the Chicago Scrum Gathering talking about the value of a team knowing what "done" means. He went so far as to state that a universally understood definition of "done" might be so powerful that the Scrum of Scrums might no longer be needed. In addition to the common notion of 'all acceptance tests are passing and the Product Owner is happy', Ken suggest the definition of "done" should include:
- Code review
- Design review
- Refactoring
- Performance testing
- Unit tests passing
- Possibly much more
You can hear more of his thinking about the definition of done in the interview he did with Scott Hanselman.
Mishkin Berteig suggests identifying repeating tasks and including them into the definition of "done." That is, if the team finds itself repeatedly creating a task for each story that looks like "internationalize (story name here)", then perhaps 'internationalize' needs to be added to the team's definition of done.
Aaron Ruhnow described how his team found "Done Nirvana" by using the following checklist to define "done"
- Coded/implemented
- Peer reviewed (pair programming counts as peer review)
- Code is run against current version in source control
- Code is commented in source control and checked in
- Code is commented with VB Commenter on Public/Friend methods
- Story/use case manual test plan updated
- Fit test written (with help of SQA person)
- UML diagram updated
- Unit tests written and passing
- 90 percent code coverage achieved
- Build and package changes are communicated to build master (i.e. introducing a new file or something)
- Task list hours are updated and task is closed out
- All to-do items in code are completed
To finish this off on a light note, have a look at Tony Clark's comic interpretation of "done", which can be found on the Implementing Scrum blog.
Leave a comment and share what your definition of "done" is.
