What is Definition of Done (DoD)?

3 September 2008

Dhaval Panchal
SolutionsIQ

Definition of done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your team’s definition of done. Verifying that your team’s DoD meets these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well.

DoD is a checklist of valuable activities required to produce software.

Definition of Done is a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product. Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts.

DoD is the primary reporting mechanism for team members.

Reporting in its simplest form is the ability to say, “This feature is done.” After all, a feature or Product Backlog Item is either done or it is not-done. DoD is a simple artifact that adds clarity to the “Feature’s done” statement.  Using DoD as a reference for this conversation a team member can effectively update other team members and the product owner. 

DoD is informed by reality.

Scrum asks that teams deliver “potentially shippable software” at the end of every sprint. To me, potentially shippable software is a feature(s) that can be released, with limited notice, to end users at the product owner’s discretion. Products that can be released to end users with two days can be reasonably said to be in potentially shippable state. Ideally, potentially shippable is equivalent to the Definition of Done.

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)

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:

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

Chris Sterling recommends that for activities that cannot be included for a sprint/feature, teams should, “Discuss all of the obstacles which stop them from delivering this each iteration/sprint”

Common root causes for impediments include:

  • Team does not have the skillset to incorporate activities into the definition of done for a sprint or for a feature.
  • Team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)
  • Team members are executing their sprint in mini-waterfalls.

    * Aha! Here’s an opportunity to be more cross-functional and share responsibilities across functional silos.
DoD is not static.

The DoD 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 auditable checklist.

Features/stories are broken down into tasks both during sprint planning and also within a sprint. The DoD is used to validate whether all major tasks are accounted for (hours remaining). Also, after a feature or sprint is done, DoD is used as a checklist to verify whether all necessary value-added activities were completed.

It is important to note that the generic nature of the definition of done has some limitations. Not all value-added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist. The team has to consciously decide the applicability of value-added activities on a feature-by-feature basis. For example, following user experience guidelines for a feature that provides integration point (eg: web service) to another system is not applicable to that particular feature; however, for other features within the system that dointerface with a human being, those user experience guidelines must be followed.

Summary

The definition of done is orthogonal to user acceptance criteria (functional acceptance) for a feature. It is a comprehensive checklist of necessary, value-added activities that assert the quality of a feature and not the functionality of that feature. Definition of done is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level (feature, sprint, release).

Article Rating

Current rating: 4.8 (5 ratings)

Comments

James Peckham, CSP,CSM,CSPO, 9/7/2008 3:57:49 PM
One thing we struggle with in our organization is the popular belief that nothing is ever 'done' so the word itself is what people get hung up on. I'm still trying to find a verbage that communicates the Definition of Done's purpose to our organization or some common ground to bridge scrum and waterfall muscle memory.

The important concept is that to one person, 'done' may be 'installed into production with 0 outstanding defects. To me it will be refactored to a coding standard, cleanly coded, good design, good automated unit test coverage. To the product owner it may just be "meets the need and is tested".

We may all overlook the things necissary to be put into a production environment as 'stuff to do' not realizing that we could possibly add it to our definition of 'done'.

How many times have you had to update your integration plan at the end of the release prior to deploying? Couldn't this have been updated during the sprint? During a backlog item's lifespan?

Definition of done is a tough thing for organizations to grasp I think.
Kristian Bank Erbou, CSM, 9/25/2008 6:21:17 AM
Definition of Done is mainly a theoretical discussion, I think. When is something done? In my team we work with some fairly basic terms to define when a story is "done"

- The feature / story has been coded
- It has been tested by the team collaborating with our Product owner (unittest, reviewed, tested for scalability if needed etc)
- It has been released to our staging environment
- Once released to staging our Product Owner and external testers either put their thumbs up or down. If they are happy it is "Done" period.

Agreeing on a DoD isn't hard if you focus on writing good, decoupled stories which do not have hard coupling and dependencies to other stories in your sprint. If you are unable to define a story as being "Done" before you move on to work on another story your Product Owner isn't doing his or her homework when preparing for the initial Estimation Meetings and you and your team haven't done your homework in preparing the sprint by opposing to upcoming stories which have a vague or unclear DoD.
Stephen Reed, 8/20/2009 4:32:25 AM
There once was a man whos last words encapsulated the words it is done: <ΓÇ£It is finished!ΓÇ¥ (John 19:30). JesusΓÇÖ last words meant that His suffering was over and the whole work His Father had given Him to do, which was to preach the Gospel, work miracles, and obtain eternal salvation for His people, was done, accomplished, fulfilled. The debt of sin was paid.> So what is my point! That what Dhaval says in his Summary pretty much says exactly that. "Definition of done is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level" - even spiritual I guess!
Doug Shimp, CST,CSP,CSM,CSPO, 1/14/2010 3:42:59 PM
Really 4 levels of done is what I see.
Done at the task is a simple one - convince your teammate
Done at a story - commitment to the product owner
Done at a sprint - sprint goals and commitment for the set of stories
Done at a release - PO decision about what it take to release

Commitment Based Planning: http://advancedtopicsinscrum.com/4-sprint-management/attachment/4-2-commitment-based-planning-v3d/

There are more ways to dice this. What I find useful is a dialog driven approach that enables learning and occurs just in time. As long as it provides enough structure to remind us of what conversations we need to have when so that we do the right thing, it is a good thing.

You must Login or Signup to comment.