Definition of Done (DoD) - It's Too Critical To Ignore

Q: Does a sprint end when sprint length is over or is there any better way of articulating end of the sprint?
Ans: Ideally, each team should have their definition of DONE at user story, sprint and release level. DONE in agile means that a team should define their commitments to evaluate completion against this definition.

Q: What's the importance of DONE in Agile? Can Agile add much value without having good discipline for DONE?
Ans: DONE = "value" in Agile. If you need your product development process to deliver "value" then you better define "done" for your team. Poor definition of done means poor value in the end.

Q: Is there any standard Definition of DONE (DoD)?
Ans: NO - DoD is a joint team commitment that team agrees to deliver at user story, sprint, and release level. This commitment is specific to the product needs and team agreement. If your organization has multiple Scrum teams then each of these team should have their own DoD. Organization may define DoD guidelines for teams as reference.

Q: Agile is not working for my team. What could be the potential reason for it?
Ans: One of the most common reason of Agile failure is not to have "shared" and "agile" meaning of definition of DONE. For a team, story is DONE as soon as engineer checks in his code. For other team, story is DONE when code passes unit testcases, QA verifies it, and product owner accepts it. This is just a simplified example where two teams get a different value out of the same process. There could be other reasons but roughly half of the teams suffer from "poor" or "no" definition of DONE.



RULE OF THUMB: Main goal of Agile is to deliver a potentially shippable software (value) at the end of each sprint. This means that the team:
  • Has a common understanding of what DONE means at user story, sprint, and release level
  • Works in a way that deliverables of the team are incremented with each iteration - from release notes to software to technical documentation - by the end of the iteration it is all advanced to the degree necessary to support release.
  • Follows agreed discipline
  • Delivers potentially shippable product at the end of the sprint

It also means team values:
  • Containment of QA to the sprint
  • Frequent builds of working code with incremental functionality
  • QA testing stories as early as possible so team tries hard to get stories to engineering "done" quickly (minimize story cycle time)
  • Inspection of incremental deliverables by Product Owner if they desire
  • Minimization of waste & technical debt

What can you do?
  • If you never heard about DoD then please learn more about it. You may read articles in the reference section and work with your team to define DONE. A new team (less mature) might have a simple definition of DONE and may be tempted to create lots of tasks to reflect process.  A more mature team will have a stronger definition of DONE and will be less tempted to create process-tasks and will focus more on software deliverables.
  • DoD is not static. It changes over time. Organizational support and the team’s ability to remove impediments may enable the inclusion of additional activities into the DoD for features or sprints. 
  • DoD is an audit checklist. It can be used to validate whether all major tasks are accounted for. Also, after a feature or sprint is done, DoD is used as a checklist to verify whether all necessary value-added activities were completed.
  • A definition of DONE is only good if it is living and is part of a team's DNA.  If the team does not know its DONE by heart then the practice is no good.  It would be smart to put a team's "done" in front of it at the beginning and end of each iteration - if only for a moment to remind them & to create an opportunity to upgrade it.   Team members should be encouraged to tape the definition to their monitor.  
  • ScrumMasters may do well to put it in front of the team at Scrum regularly until it sinks in. A Scrum Master should be on the lookout for opportunities to improve a team's DONE.  Process problems often indicate a need for an upgrade.
Mr. Agile is explaining definition of done to Amy in his latest discussion in the office xerox room. Enjoy this cool video and let Mr. Agile know if you have any question about Agile.


References

    6 comments:

    1. Hi Yogesh,

      I think your website is a great platform to share and talk about Scrum.
      I have a question although not so relevant to the post above but in general. What do you think are the primary factors that needs to be considered in determining the length of one Sprint cycle. Do you think 2 weeks is better than 4 week cycles? In my company we have 4 week cycles; there is lot of chatter about moving to 2 week cycles to give business more flexibility. Just wondering what are your thoughts on this.

      Thanks
      Gaurav

      ReplyDelete
    2. Gaurav,

      SIMPLE RULE OF THUMB: Ideal length of sprint is inversely proportional to the agility of your team. In other words if your team is very Agile then shorter sprints are better, however, if your team is less Agile then larger sprints are better.

      Please review more details in my blog for ideal sprint length: http://www.agilehelpline.com/2011/03/sprint-length.html

      How agile is you team?

      Thanks,
      Yogesh.

      ReplyDelete
    3. Hi Yogesh, I've been reading a lot about DOD and everybody explains what it is and how to determine it. However nobody speaks of how to enforce it, when to check on it, and what to do if it is not met at the end of the release. There are some items that are implied - such as coding, testing, etc. But there are also secondary items such as update online help file or user guide, performance and regression testing: items that in the eyes of the team might look like "postponable". So happens if coding and testing are done, we are at the end of the sprint, demo is successful, but some items in DOD are not fulfilled?

      Thank you,
      Nataliya

      ReplyDelete
    4. Hi Yogesh, I've been reading a lot about DOD and everybody explains what it is and how to determine it. However nobody speaks of how to enforce it, when to check on it, and what to do if it is not met at the end of the release. There are some items that are implied - such as coding, testing, etc. But there are also secondary items such as update online help file or user guide, performance and regression testing: items that in the eyes of the team might look like "postponable". So happens if coding and testing are done, we are at the end of the sprint, demo is successful, but some items in DOD are not fulfilled?

      Thank you,
      Nataliya

      ReplyDelete
    5. Hi Yogesh, I've been reading a lot about DOD and everybody explains what it is and how to determine it. However nobody speaks of how to enforce it, when to check on it, and what to do if it is not met at the end of the release. There are some items that are implied - such as coding, testing, etc. But there are also secondary items such as update online help file or user guide, performance and regression testing: items that in the eyes of the team might look like "postponable". So happens if coding and testing are done, we are at the end of the sprint, demo is successful, but some items in DOD are not fulfilled?

      Thank you,
      Nataliya

      ReplyDelete
    6. Hi Yogesh,
      Thank you for the great article. One thing I am still not sure about: how to enforce DOD and what do we do if at the end of the sprint some of DOD items are not done?
      There are certain items in DOD that are implied - coding, testing, etc., but some are somewhat secondary, such as performance and regression testing, updating of online help file and user guide: things that in the eyes of a team can be viewed as "postponable". So we are at the end of the sprint and demo is a success, but some items in DOD are not fulfilled. What do we do?

      ReplyDelete