The Power of Done

by Chris Sims on Oct 13, 2008 |

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.

Related Editorial

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

Infographic: Just How Big is the Nerd Economy

Agile Maturity Model Applied to Building and Releasing Software

Enterprise-class API Patterns for Cloud & Mobile

Agile workshops and training

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Team Defined, company supported... by Kevin E. Schlabach Posted

core definition... by Kevin E. Schlabach Posted

How to define 'done' for customer? by Sjoerd Andringa Posted

'Definition of Done' Mind Map Diagrams by tribhuwan negi Posted

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

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.

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?

'Definition of Done' Mind Map Diagrams by tribhuwan negi

'Definition of Done' for User Story and 'End of Iteration' reference checklist with Mind Map Diagrams is here.
blog.tribhuwannegi.com/2012/03/mind-map-diagram...