Definition of Done

WRITTEN BY Derek Huether

definition of done

Is it done, is it done done, or is it done done done?

I bet you’ve asked that question before, if you are in the business of application development.  When asking the questions, it is important to note who you are and your level in the organization. Delivery teams, program teams, and portfolio teams define done differently. For certain, we need is a clear definition of done at each level of the organization.

Definition of Done

The definition of done (DoD) is when all conditions (acceptance criteria) that a software product must satisfy are met, to be accepted by a user, customer, team, or consuming system.  We must meet the definition of done to ensure quality.  It lowers rework, by preventing user stories not meeting the definition from being promoted to higher level environments. It will prevent features not meeting the definition from being delivered to the customer or user.

User Stories

The most common use of Definition of Done is on the delivery team level.  Done on this level means the Product Owner reviewed and accepted the user story. Once accepted, the done user story will contributed to the team velocity.  Meet all of the defined criteria or the user story is not done.

The below examples might be included in the User Story DoD:

  • Unit tests passed
  • Code reviewed
  • Acceptance criteria met
  • Functional Tests passed
  • Non-Functional requirements met
  • Product Owner accepts the User Story

Features

Done on this level may mean it qualifies to add to a release.  Not all user stories need to be completed. Rather, it means the feature may be sufficient to satisfy the need. Once accepted, the done feature will contribute to the release velocity.  Meet all of the defined criteria or the feature is not done.

The below examples might be included in the Feature DoD:

  • Acceptance criteria met
  • Integrated into a clean build
  • Promoted to higher level environment
  • Automated regression tests pass
  • Feature level functional tests passed
  • Non-Functional requirements met
  • Meets compliance requirements
  • Functionality documented in necessary user user documentation

Epics

Done on this level may refer to a organizational strategic priority, portfolio plan item, or some other collection of features that satisfied a market need.  Not all user stories or features need to be completed. Rather, the epic may be sufficient to satisfy the need. Once accepted, the done epic will contribute to throughput calculations to see if the supply is in balance with demand.

The below examples might be included in the Epic DoD:

  • Non-Functional requirements met
  • End-to-end integration completed
  • Regression tests pass
  • Promoted to production environment
  • Meets defined market expectations

Summary

Just as the definition of ready is super important, so is the definition of done.  Never start work on something until you have agreed on the definition.  Be consistent. Be clear. Have a shared understanding.

leave a comment

Leave a comment

Your email address will not be published. Required fields are marked *

3 comments on “Definition of Done”

  1. Amit J Bhattacharyya

    Thanks Derek for this neat and crisp compilation on DoD.
    I just have seen from experience that a number of times the user story DoD and the features DoD really overlaps or coincides in real life.

    I totally appreciate the segregation here and would agree that the last 2 points of features DoD is quite exclusive. But I have seen that in the scrum lifecycle of a user story or stories if “Automated regression tests pass” was -ve then QA teams would not approve it and raise issues against it and then it is not able to proceed to the Product Owner and other stakeholders for the Done assessment itself.

    The other one I have seen, being a part of necessities for user story DoD is “Integrated into a clean build”. As without that, the development team will not be able to pass the hurdle to prove that delivered story is really releasable which then in turns hurts it’s efforts to earn the credibility of done.

    Would love to know your thoughts and yes definitely :) I will be sharing this good post on twitter.

    Reply
  2. Zeeshan Siddiqui

    Should ‘No open Critical/High Severity defects’ be included in DoD?

    Reply
    • Derek Huether

      Absolutely, I agree it should. I don’t specifically call it out, but I believe that should be part of the fundamental acceptance criteria. Quality should be a core consideration.

      Reply