Definition of Done

In an agile development model, you and your team releases each takt software that your stakeholder can consume immediately. That means that the software, which you develop, needs therefore to be ready for distribution to anyone in the company for review or  it can be shipped to any external stakeholder as well.

You and your team specify, design, develop and test these potentially shippable products during the sprint. Thus, one of the most important aspects for your agile development project is the question, when you should consider a development task as done.

Formalized Done Criteria that match with the characteristics of your development product help you with this release decision.

In the Literature…

You find different definitions for done criteria in the literature. The article → Definition of Done Reference on the Scrumedge-Blog, for instance, talks about done criteria for development items, for concept items or for shipable units (releases) in general.

Development Project

For development projects, the blog for example defines the following criteria:

  • Code Complete
  • Unit tests written and executed
  • Integration tested
  • Performance tested
  • Documented (just enough)

Concept Item

And for concept items, such as software-designs, it foresees the following criteria:

  • Design Reviewed
  • Implementation plan defined

The blog article also offers a complete list of done criteria for development-takts, projects, or releases (see there). The weak area of the presentation format choosen for the complete list is that it makes not transparent, which item is relevant to whom in the organization.

Scrum

You find this transparency in a different article. The Scrum Aliance explains in → What is Definition of Done that you normally find different levels of done criteria within an organization:

„In reality, many teams are still working towards a potentially shippable state.  Such teams may have a different DoD at various levels:

  • Definition of Done for a feature (story or product backlog item)
  • Definition of Done for a sprint (collection of features developed within a sprint)
  • Definition of Done for a release (potentially shippable state)

This article also proposes a procedure that you can follow, if you want to decide to which DoD in the hierarchy a particular activity belongs:

„There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release.  Ultimately, the decision rests on the answer to the following three questions:

  • Can we do this activity for each feature? If not, then
  • Can we do this activity for each sprint? If not, then
  • We have to do this activity for our release!

Defining Definitions of Done

Although you find different proposals for Done Criteria in the literature, it depends very much on your project, which specific done criteria you should select.

In my experiences, it makes sense that you define these criteria together with your scrum team, perhaps after you have analysed the current quality topics that you and your team is facing.

Assuming that you work for a team of ten that concentrates on new feature developments: In your first version you should concentrate on the criteria that you and your team can influence, and that define, when a particular backlog item shall be considered as done. Normally you choose testing criteria, which support your team directly, such as Unit Tests, or manual testcases on feature level. Also relevant is feature documentation, etc.

The above literature proposes integration, and performance tests. If you develop in a larger context, i.e. together with other teams, integration of performance tests are often only possible in consolidated coding lines. These tests are thus not possible in the moment, when you release your backlog item, and – in these cases – should not be choosen as criteria.

Once you have defined your criteria, you should use them on each item in all forthcomming sprints to decide if and when you can close a backlog item. As you and your team can change the criteria dynamically, you should review and extend your initial done criteria, once you have better knowledge.

Additional Information

If you liked this article, why don’t you subscribe to my → mailinglist, → follow me on Twitter, or → like me on Facebook?

In the following older articles on my blog can you find more information related to the current blogpost:

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

    I

    This entry was posted on Montag, Januar 17th, 2011 at 8:38 pm. It is filed under Agile&Scrum, Thema des Tages and tagged with , , . You can follow any responses to this entry through the RSS 2.0 feed.

    Andreas Rudolph - Fotoshop Andreas Rudolph - AS-Photo-Project.de

    Comments are closed.