The Power of Done
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
- Performance testing
- Unit tests passing
- Possibly much more
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.
- 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
Leave a comment and share what your definition of "done" is.
Team Defined, company supported...
Kevin E. Schlabach
I also agree with Mishkin Berteig that it is better to include repetitive tasks in the checklist than try to remember on each story to enforce it with a task.
Teams should also be allowed to add/remove from the list. For example, if the team is doing pair programming, they might be allowed to skip the code review (depending on team make-up and pair rotation).
One of the biggest issues I see with the definition of DONE on most teams is what happens after the sprint is over and bugs are found.
I'm not sure I agree with Ken Schwaber that a clear DONE list removes the need for a scrum of scrums. The scrum of scrums is to keep different teams in sync, and I believe having those conversations at once is more productive and efficient than using a DONE checklist as a way to make sure those conversations happened. The value of a stand-up includes the unexpected conversations. I think the DONE list will bypass those unexpected but necessary surprises and they might haunt the team later.
Kevin E. Schlabach
Agile Commentary Blog
Kevin E. Schlabach
James Shore has a post about DONE DONE. This thread is focused on the tasks required to be done, but I like to constantly remind teams about the philosophy of done and this link provides a good summary.
How to define 'done' for customer?
How do others agree on the definition of 'done' with the customer? Specifying all details up front doesn't seem very agile. Any thoughts?
'Definition of Done' Mind Map Diagrams