Done Criteria

In starting a project, one of the important steps we need to do is to and define and agree on what "done" means. There are plenty of good examples around that we can draw from as inspiration for our own lists. On my current personal project, I just put together my own definition of done.

A feature is "done" when:

  1. Users can use the feature, are happy with it, and any major design flaws or bugs are closed
  2. UI for the feature has been styled and designed to look nice
  3. UI for the feature works for normal as well as high-contrast mode, and works equally well for colour blind users
  4. Keyboard accessors/shortcuts and tab order are set
  5. End user help/tooltips work
  6. If necessary, any sample data needed to test the feature is ready
  7. Automated unit tests are written, with a high enough level of coverage
  8. Automated UI "smoke" tests have been recorded and pass
  9. Load tests written and pass
  10. Each button click/interaction results in the minimal number of service calls
  11. All UI components are hardware rendered, virtualization is enabled, and no data binding errors
  12. Any auditing/tracing code is added, and the output is useful and readable
  13. Any potential failure scenarios are catered for
  14. Feature is tested for any major memory leaks
  15. Automated database migration scripts are ready and tested
  16. Security permission checks have been implemented and validated via automated tests

Some of this revolves around performance. This isn't about premature optimization, just checking for obvious problems. If I find out I'm accidentally doing a SELECT N+1 that isn't a problem on my laptop, but is a problem in a reasonable set of sample data, I want to resolve that before claiming the feature to be "done".

Every project is different. What does your definition of done look like?

A picture of me

Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool for .NET applications.

Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.

02 Aug 2010

My criteria:

When it meets the business requirements


Because everything you have listed should be listed as business requirements - not open to developer interpretation on a best practice' basis. And yes, that means many of those things should be fed back to the business by development as "perhaps you should think about ...." requirements


02 Aug 2010

@Jak, of course you'd run those things by the business ("can you afford automated UI testing?"). But if they say "yes", you need to capture that somewhere - that's where I find the definition of done useful. Otherwise you'll be so busy focussed on the unique parts of the feature to forget to make sure it works in high contrast mode or doesn't do a SELECT N+1.

In this case I am the business. All of those are my "release criteria" for all features :)

02 Aug 2010

It's called a "Non Functional Requirements Specification"

And needs a lot more in it than just your list


02 Aug 2010

Nice list Paul. Does 1. mean that every feature must be accepted by the users? Which raises the question, what is the criteria for acceptance?

14 Aug 2010

Your number 10 is a little strange. Exactly how do you determine that?

As for my "done" criteria list? Please wait a while, it's not quite done ...