In a previous article, we talked about what is a Definition of Done (DoD) and common misunderstandings related to Acceptance Criteria.  In this article, I will provide you with the steps to build your own DoD using my favorite approach.


When Do You Create a Definition of Done?

If your team is new to Scrum, the DoD needs to be created before the first Sprint Planning meeting.  Why?  If you do not know what is considered done, you are not going to have an effective Sprint Planning.

If you have an existing Scrum Team that is fumbling around without a DoD, then I recommend using your next Sprint Retrospective as an opportunity to create (or improve) your DoD.  An existing Scrum Team without a DoD is not really doing Scrum but since the group is functioning at some level of performance, there is no need to stop the line and fix this problem immediately.

Regardless of when you build the DoD, I recommend inviting both the Scrum Team and their key stakeholders to the conversation.  There are two reasons for this choice:  First, it is often illuminating for the stakeholders to see everything the organization has asked the Scrum Team to do in order to bring a product or service to the market.  Second, if something needs to be changed — a policy updated or a new person added to the Scrum Team — the right people are in the room to make the decision immediately.


Four Steps to Creating a Definition of Done

  1. Identify everything you need to do.  Give everyone on the Scrum Team, plus their key stakeholders, a small packet of Post-it notes and a Sharpie (or their digital equivalents).  Next, ask the participants to write down everything a typical team needs to do in order to bring a Product Backlog item from ideation to delivery to the customer including any artifacts or documentation.  Each person should have from five to ten items.  As I mentioned in this older article, the purpose of this step is to roughly document the entire value stream.
  2. Review the items.  At this point, there should be a huge pile of post-it notes.  The first action is to go through the stack to spot the duplicates.  While the team is pruning out the duplicates, someone will need to post a sheet of chart paper on the wall (or the digital equivalent) and draw a squiggly blue line across the middle (see the picture to the right).  Next, review each item with the Developers with this question: “Will you complete this activity for each Product Backlog item in the Product Backlog for every Sprint?” 
    • For items the Developers commit to do every Sprint, put those post-it notes on the bottom half of the chart paper.  This section represents the potential DoD and will include typical software development activities like design, analysis, code, test, documentation, etc.
    • For items the Developers do not commit to do every Sprint, put those post-it notes on the top half of the paper.  This section represents tasks, activities and artifacts that will potentially not be part of the DoD.
  3. Identify the impediments.  In the top half of the chart paper, there should be a hodgepodge of items — 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.  The purpose of this step is to understand why these items exist and what are the impediments which prevent the Scrum Team from completing them each Sprint.  In some cases, the activities are not the Scrum Team’s responsibility, as it is currently configured.  In other cases, it does not make sense to do these activities every Sprint due to a high transaction cost, based on how the organization, or team, is structured today.  For other items, it would be possible for the Scrum Team to incrementally complete these activities each Sprint either through a policy change, a shift in the how the Scrum Team is staffed or through some simple training.For instance, suppose the Developers say they cannot complete automated integration testing every Sprint since they do not have a dedicated testing environment.  Whomever is facilitating this activity then asks the stakeholders if they can provide a dedicated testing environment.  If they can, the activity in question moves to the bottom half of the page to be included as part of the DoD.  If they cannot, then the item is placed on the blue (water) line and a specific action item is identified on when this issue will be resolved.  Repeat this process until all the items in the top half of the page have been discussed and action items (with owners) identified.
  4. Commit to the DoD.  The final step is for the Developers to commit to the DoD.  For the sake of clarity, the DoD includes ALL items below the blue waterline. The items on, or above, the waterline are not included as part of the DoD since they have outstanding impediments that have yet to be resolved (once the action items have been resolved for the item on the waterline, those activities will become part of the DoD in the next Sprint).  Since this is a decision which requires ownership and commitment by the Developers, I recommend using the Decider/Resolution protocol, but Fist of Five or Gradients of Agreement could work as well.  If there is anything less than enthusiastic support, the facilitator will need to migrate items from the bottom half of the page to the top half of the page until a DoD is created which receives enthusiastic support from all the Developers.  Why?  Because the durability of the DoD is based on the Developers’ willingness to put it into practice.  The more enthusiastic they are about the DoD at this stage means the more they will use it each and every day and defend it when under pressure.

Assessing the Quality of the Definition of Done

How can one tell if the DoD is sufficient?  The goal of each Sprint is to release a usable product Increment to customers and end users.  If the product Increment is not put into the hands of the customers and end users by the end of the Sprint, this delays feedback.  Without feedback, the inspect-and-adapt cycles become bogged down.  This is a serious problem in Scrum.

Unfortunately, the exercise described above will likely identify many, many reasons why the product Increment cannot be put into the hands of customers and end users.  In the interests of transparency, these reasons would be all the items that remain on, or above, the waterline.  The Large-Scale Scrum community calls all these activities the Undone Work — any difference between “in use” and the DoD — and they represent organizational technical debt which prevents individual Scrum teams from getting to done within a Sprint. 

When the difference between the DoD and the Undone Work is small (i.e., there are very few items on, or above the waterline), the DoD is considered strong.  This is good because not much else needs to be completed after a Sprint in order to ship the product Increment.  Not many organizations start this way.  

When the difference between the DoD and the Undone Work is large, the DoD is considered weak.  This is much more common because most organizations are not designed to rapidly release product Increments each Sprint.  For business leaders and ScrumMasters, these activities represent the first draft of their Impediments Backlog.  In either case, a strong DoD or weak DoD, everyone has a responsibility to strengthen and improve the DoD over time.