The Power of Done

Posted by Chris Sims on Oct 13, 2008

Sections

Process & Practices,

Architecture & Design

Topics

Delivering Quality ,

Software Craftsmanship ,

Delivering Value ,

Agile

Tags

Podcasts ,

Best Practices

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"

1. Coded/implemented
2. Peer reviewed (pair programming counts as peer review)
3. Code is run against current version in source control
4. Code is commented in source control and checked in
5. Code is commented with VB Commenter on Public/Friend methods
6. Story/use case manual test plan updated
7. Fit test written (with help of SQA person)
8. UML diagram updated
9. Unit tests written and passing
10. 90 percent code coverage achieved
11. Build and package changes are communicated to build master (i.e. introducing a new file or something)
12. Task list hours are updated and task is closed out
13. 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.

1. Back to top

   Team Defined, company supported...

   by Kevin E. Schlabach

   I believe the company (or the agile portion of it) should have a baseline list of DONE gates. Many of the items listed above fall into this bucket.
   
   
   
   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

   Reply

2. Back to top

   core definition...

   by Kevin E. Schlabach

   Found this later...
   
   
   
   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.

   Reply

3. Back to top

   How to define 'done' for customer?

   by Sjoerd Andringa

   Having such a definition for 'done' is great for internal matters; developers should know when they can close a backlog item. But what about the definition of done by our customer / product owner? I'm currently managing a project in which we have to work on a fixed budget for each sprint, so we need to plan very accurately. When after everything has been delivered a bug shows up (even if all unit, functional and integration tests pass) I have to tell the customer the work was 'done' and fixing this bug will require a new assessment, planning and thus money spent. Obviously the customer won't agree the work was 'done' here, potentially resulting in a conflict. Currently we have agreed on a short acceptance period (of 3 days) in which the customer should test the new functionality plus another period of 2 days in which we will fix problems that came up during the acceptance period. After that, the work has been 'done'. The downside is that our sprints take one work week longer and not all problems show up during those 3 days.
   How do others agree on the definition of 'done' with the customer? Specifying all details up front doesn't seem very agile. Any thoughts?

   Reply

• Older >