What Does Done Mean for Your Project?

One of the problems I see in projects is that there is not a sufficient definition of done. For agile teams, it’s not clear what done means for a timebox. For non-agile projects, the team may not agree on what done means for a milestone or for a release.

For an agile team, do you know what done means for your timebox? Is all the code tested? By whom? Is it all checked in? Does it build without problems? Can you demo the product? Can you release the product? I much prefer product that is developed, fully tested by developers, system tested by the testers, and could be released–what I call release-able. But that might not fit for your project. If the product is only demo-able, make sure everyone knows that you still have technical debt and will need another timebox for testing and fixing.

For every team, develop release criteria. That way you’ll know what done means for the project as a whole.

For a team using any lifecycle other than agile, make sure you have interim milestones and criteria for those milestones, so the team has early feedback about the project’s progress. And, measure your progress towards your release criteria.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in agile and tagged , , , , . Bookmark the permalink.

5 Responses to What Does Done Mean for Your Project?

  1. Miranda says:

    Great post! I like the idea of developing release criteria. But saying “We can release when…” it can give a clear picture of what the finished product should look — and function — like as a whole.

  2. Kelly Waters says:

    I’ve written a couple of blog posts specifically about what constitutes ‘done’ in an agile development environment; see here:


    Kelly Waters

  3. Defining “done” is an oft-neglected fundamental. I have recently taken over a project (everyone else left). The first thing I did was define what “done” means. In the previous two years, no one had defined “done.” Gosh.

  4. My experience says that a project is done when customer can use promised features in it’s business (probably with confirmed limitations). Otherwise it is not done, independent on ‘done’ defections you have declared (and even ‘signed’ with a customer).

    When your definition says that the project is done (commits are done, tests are passed and so on are), but the customer cannot use it, you have a choice: change your ‘done’ definition or get a conflict with the customer.

  5. Mitch Lacey says:

    HI Johanna,

    I’m a little behind. :) Great article. I have an exercise that I run and have documented it in my upcoming book, you may like it. I’d love to hear your thoughts. Check it out at http://mitchlacey.com/index.php/Adopting-Agile/Chapter-61-Review-Draft-Defining-Done.html

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>