Don’t Get Stuck on a Definition of Done

What does it mean to be ‘done’? Many agile software development teams adopting Scrum, XP or Kanban struggle with their ‘definition of done’.

They usually try to derive a set of measurable criteria that will enable them to verify that a work product is fully complete and ready to be deployed to the user community. Most definitions of done include things like:

  • Story written and estimated
  • Story acceptance criteria defined
  • Code written
  • Code unit tested
  • Code integrated into the build
  • etc.

The problem with kind of universal done definition is that it treats all aspects of the project the same. Stories should not follow the same done criteria as sprints. They have unique characteristics and thus their definitions of done will be different. Trying to lump them altogether creates a problem that quickly becomes too complex to solve.

Create three definitions of done

The three major elements of a major software project deserve their own definitions of done:

  • Stories and the associated code
  • Sprints
  • Releases

This will (hopefully) make it easier to create the definitions because they will be focused rather than encompassing.

There are always exceptions

If you want to take this a step further, consider implementing an exception process. That is, not all done criteria will apply to every project artifact.

For example, some code modules will require performance testing due to their complexity or data volume requirements. Other modules will not because they are accessed infrequently or used in low stress situations. You could include performance testing as a done criterion and define a process for granting an exception if warranted. Usually, the Scrum Master and Product Owner would have to approve the exception.

Don’t get stuck defining done. Keep your definition(s) simple and expend your energy on delivering results that add value. Make sense?

Updated: March 21, 2011 — 9:37 pm