When, How and Why Definition of Done Should Be Extended

December 7, 2007 by Artem

Definition of done is one of the central concepts of Scrum process. Every iteration the team is supposed to release an increment of software that is fully done. Ideal Scrum team every iteration delivers software right to the customer hands, manages to arrange the trainings, print documentation and so on. Most of the real world teams, however, aim at somewhat smaller goals. What exactly is expected to be delivered by the iteration end depends on the team's definition of done.

Evolution of Done

There are different checklists and recommended definitions of done. However, there is no best definition that can be used by all the teams in the world. It is especially difficult to choose a reasonably wide definition during the transition phase from the traditional plan-driven methods, because in such situations the final testing phase of delivering software might easily take longer than half of the sprint.

There is no universal recipe for choosing the good definition, but as a rule of thumb it might be useful to adopt the very minimal possible definition from the beginning and then iteratively widen it. The point is to standardize what the team is actually able to reach and improve in the controlled manner without "adopting" standards the team is not actually able to follow. The minimal definition might be as loose as "Product Owner has to explicitly accept the delivered backlog items". Then it can be widened with e.g. "some automated tests included", "critical code code reviewed", "all the changes are developed in the test-driven mode", etc.

Your Experience

How do you see the evolution of the definition of "done"? Where did you start and how much does your definition change over time?

Permalink