Definition of Done: Define It or Doom Your Sprints

A Definition of Done (DoD) is non-negotiable if you want to #DoBetterScrum.  The best Scrum Teams co-create their DoD with their Product Owner, Scrum Master Developers and stakeholders.  To learn more about what steps you need to take in order to build a strong DoD, read on.

When to create a Definition of Done

If your team is new to Scrum, one of the first tasks you need to complete is to create a DoD prior to your first Sprint Planning meeting.  IME, without a clear understanding of how your team defines quality, you cannot have an effective Sprint Planning meeting.

For existing Scrum Teams that lack a DoD, the next Retrospective is an ideal time to create (or refine) it.  Please keep in mind, the lack of a DoD is a high priority issue that both the Scrum Master and Product Owner need to address.  There are no benefits associated with delaying this conversation.

Who creates the Definition of Done

The obvious participants are the Developers, Product Owner and Scrum Master.  I also recommend including the key stakeholders in this discussion.  There are two reasons for this.  One, stakeholder participation gives them insights into the full scope of what is required in order to deliver the product or service.  Two, when discussing impediments to getting to done, it is often stakeholders who have the authority to eliminate these impediments.  By having them present in this discussion, decisions on how to resolve these impediments can be made on the spot.  

Four steps to creating a Definition of Done

     1.  Identify Activities: give everyone on the Scrum Team, and their key stakeholders, some post-it notes and a marker (or their digital equivalents).  Next, ask them to write down every task that is required to take a Product Backlog item from conception to delivery; be sure to include any documentation that may be required.  Set the expectation that each person should strive to identify from ten to fifteen items. 

     2.  Review & Organize: at this point, you will have a large collection of notes that roughly outlines the value stream of the Scrum Team.  Next, post a large sheet of chart paper on the wall (or the digital equivalent) and draw a blue line across the middle.  Start your review by removing the duplicates.  With the remaining items, select a post-it note and ask the Developers, “Will you complete this activity for each Product Backlog item in every Sprint?”.  

• If they say, “Yes”, place the post-it note below the blue line.  These items represent the potential DoD and will include typical software development activities like design, analysis, code, test, documentation, etc.  
• If they say, “No”, place the post-it note above the blue line.  These items represent tasks, activities and artifacts that will potentially not be included as part of the DoD.  

Continue until all the items have been moved to one side of the line or the other.

     3.  Identify Impediments: in the top half of the chart paper, there should be a variety of necessary, but unrelated tasks: all sorts of documentation, various compliance activities, artifacts related to project or program governance, specialized reviews, different types of testing and other infrequent development activities.  This next step is to understand why these tasks exist and what impediments are preventing the Scrum Team from completing these activities each Sprint.  This is why the stakeholders are present in this meeting – they need to hear directly from the Developers what is blocking them.  Here are some common reasons:

• Some activities might not be the Scrum Team’s responsibility.
• Other activities might not be feasible to do every Sprint due to high transaction costs.
• The current organizational design prevents the Scrum Team from working on these activities.

For many of these activities, it is possible for Scrum Team to complete them each Sprint through a policy change, adjusting the membership of the Scrum Team or with training.  

• If that is the case, move the activity to the bottom half of the page to be included as part of the Scrum Team’s DoD.  Be sure to note what conditions must be true for this to occur.
• If they cannot, place the item on the blue (water) line.  Be sure to identify an action item on who owns the issue and when this issue will be resolved.  This will be tracked in the Impediments Backlog.

Repeat this process until all the items in the top half of the page have been discussed and action items (with owners) identified.

     4.  Commitment to Quality: we now have reached the final step where the Developers commit to the DoD.  The items on, or above, the blue line are not part of the DoD since there are outstanding impediments to resolve (once resolved those items would now be part of the DoD in the following Sprint).  Because this is a decision which requires ownership and commitment from all the Developers, use decision-making protocols like Decider/Resolution, Fist of Five or Gradients of Agreement to ensure enthusiastic support.  Adjust the DoD until there is full commitment, as the Developers’ willingness to adhere to the DoD – even under pressure – will determine its effectiveness.

Evaluate the Definition of Done

How do you know if you have a good DoD?  In Scrum, the goal of each Sprint is to deliver a high-quality, usable Increment every Sprint.  This maximizes the Scrum Team’s ability to receive, and respond to, feedback.  If the Increment is not put “in use” by the end of the Sprint, feedback loops are diminished and the DoD needs improvement. 

When there is a delta between what the Scrum Team can complete within a Sprint and “in use”, that is called the Undone Work by the LeSS community.  It represents all the organizational impediments and technical debt that prevent the Scrum Team from achieving done within a Sprint.  When the Undone Work is zero, or very small, the DoD is considered strong.  When the Undone Work is large, the DoD is considered weak.

Most organizations will start with a weak DoD since they are not optimized for fast customer feedback.  That’s OK since where you start is where you start.  However, it is a Scrum Master’s responsibility to improve the DoD over time by slowly eliminating the various impediments identified through this exercise.

If you’d like to know more about we can help you improve your DoD, we offer a Scrum Team DoD “Tune Up”. Or if you think you need help is other related areas, se also offer a Scrum Team Retrospectives “Tune Up” and a Scrum Team Sprint Planning “Tune Up.”