Definition of Done

Definition of Done2018-10-03T16:51:57+00:00

Yes, done is done. But what does ‘done’ really mean?

In a traditional project or programme environment, many separate individuals and groups are involved in delivery, each playing a different role in finishing the work. So the way such organisations define what needs to be done for the work to be considered complete – a prescribed sequence of tests, sign-offs, acceptances, etc. – is spread out too. The delivery team don’t decide on these criteria, they just do as they’re told, and everyone assumes that, in this case at least, one size really will fit all.

In Agile it’s different. Everyone involved in delivery is typically working closely together all the time, but at the same time, the differences between releases and iterations mean that one size certainly would not fit all.

Hence Agile’s concern with the ‘Definition of Done’. The ‘Definition of Done’ (DoD for short) is the list of steps or tasks that must be completed before the work is finished and the team can release the product. The same definition can be used repeatedly – so it serves as a standard for product quality – but quite often it will be tweaked from release to release and even iteration to iteration.

What does a Definition of Done look like?

The following is a typical Definition of Done at story level:

  • The user working on this story is happy with the solution.
  • Some parts of the definition are straightforward product quality checks:
    • The code is all written.
    • The code has passed all tests:
      • unit, functional and system tests.
      • static analysis criteria.
      • non-functional tests (usability, performance, security, etc.).
      • user and operational acceptance tests (i.e., UAT and OAT).
    • Test coverage exceeds x percent of the code.
    • The code is physically ready to ship.
  • Other parts of the definition could relate to the wider solution rather than just the IT system. A very common set might be:
    • All documentation for the story is ready for delivery.
      • end-user manuals.
      • user training materials.
      • help desk scripts.
      • amendments to field-support resources.
      • installation guidelines and scripts.
  • Other parts of the DoD ensure the sustainability of future work. For example:
    • All unit, functional and acceptance tests for the story have been automated.
  • Inevitably, there is the question of signing the product off:
    • The product has been accepted by Product Owner.
    • Operations have authorised the system to go live.
    • Relevant business owners have accepted the product.
  • Finally, and regardless of the team’s views, ‘done’ must always include compliance with any policies or standards set by the organisation as a whole.

Of course, this isn’t very different from the ‘Definition of Done’ any traditional methodology would expect. The key differences are that:

  • The tests were identified by the Agile team.
  • They are under constant review and constantly revised to fit the current work as closely as possible, including adding new criteria and removing superfluous rules.

Publishing your DoD

Making your DoD public

The DoD must always:

  • Be publicly visible to every member of the team.
  • Be used as the standard for all stories and releases.
  • Not be skipped, circumvented, or ignored – ever.

Sharing your Definition of Done across teams

Also bear in mind that, if more than one team is working on a release or sprint, they need to share a common Definition of Done. Ideally, your Definitions of Done should be shared (and certainly closely aligned) all the way up to the level of your shared Product. Otherwise the standards the teams work will be inconsistent, and then so will the end-product.

Defining ‘Done’ above the story level

‘Done’ needs to be defined at every level at which some form of acceptance takes place. This is likely to include product, release, iteration and story levels, and perhaps epic and feature levels too. For Agile teams, the most important levels for defining done are usually the release and the iteration.

Building a multi-level Definition of Done is not hard:

  • For much of this scope, the definition may simply be an organisational standard, so it is inherited from release to release.
  • However, precisely because it is the purpose of any individual release, iteration, story, etc. to create a change, this innovation suggests that any pre-existing definition of done may need to be amended.

Note also that ‘done’ at, say, the release level is not always simply ‘All the release stories are “done”‘. The release may have its own exit criteria, perhaps relating to release-level integration, testing and release processes belonging to other teams. Likewise for products. See Epic Management for further details.

Definition of Done, productivity and technical debt

Once your DoD is in place, it will have a substantial impact not only on the quality of what you deliver but also your overall productivity. The effect of systematically eliminating waste and rework and preventing technical debt can be dramatic, but this is only logical, as this diagram illustrates:

Robust and weak definitions of done

(Adapted from Michael James’ ‘Scrum Reference Card‘.)

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Toggle Sliding Bar Area
Want to do more than just build systems?