A scrum team’s definition of done helps them continuously add value to the product and avoid backsliding or breaking things. When a product meets the definition of done, new value is available and the stakeholders can access the value whenever they choose. One way to think about the definition of done, is as a checklist that helps us guarantee the quality of the product.
If the product is software, meeting the definition of done means bringing the product to a releasable state. This doesn’t mean that the business will release the product, but that it could. Perhaps the stakeholders prefer to wait until additional features are added? It should be a purely business decision when to release, and not require additional work from the scrum team.
The Increment
Each time the product meets the definition of done, it has incrementally more value. The scrum guide calls this the increment. Think of the increment as the latest and greatest version of the product. The definition of done is a commitment that the scrum team makes regarding the quality of the increment. The team promises that each increment will meet the definition of done. They have checked all the quality checkboxes. This allows stakeholders to be confident that each new increment is usable and valuable.
Increments should be created frequently. Some teams have a new increment each time a product backlog item (PBI) is completed. Some teams create increments even more often. For example, software teams that do continuous integration may create multiple increments each day. The minimum for a scrum team would be having a new increment each sprint.
Creating The Definition Of Done
Here is one way of facilitating the creation and evolution of your scrum team’s definition of done. This example is a software development team, though a similar approach can be used in other domains. You can use this meeting agenda template to facilitate the creation of the definition of done.
Invite The Right Participants
The entire scrum team should participate in the creation of the definition of done. If there are multiple teams working on the same product, then all teams should participate. When an increment meets the definition of done, the stakeholders should be able to easily access it so that they can provide feedback on the increment. To ensure that the definition of done accomplishes this, key stakeholders should be invited to the creation of the definition of done. Stakeholder groups that should be represented might include: end users, product support staff, and system architects.
Identify The Work
Have the participants identify everything needed before any change to the product could be part of a new increment. Recall that an increment is usable and easily available to stakeholders to evaluate. Each piece of work goes on a sticky note (physical or virtual). Be as specific as possible. If a team member says “testing” get specific about what that entails and write specific sticky notes such as:
- Each acceptance criteria has an automated regression test
- All acceptance / regression tests passing
- Unit test coverage is greater than 80%
- All unit tests passing
- Manual exploratory testing has been done and no “show stoppers” found
Put all the sticky notes on a wall (again, physical or virtual). Keep asking if there is additional work needed. Are there sign-offs? Documentation updates? Compliance requirements? Eventually, the team will have captured it all. At this point, you have your definition of done.
How Often Can We Do It?
Now let’s see how frequently the team believes they can create new increments.
Put the following labels on the wall:
- Every Check-In
- Every Product Backlog Item
- Every Day
- Every Sprint
- Less Often Than Once Per Sprint
One by one, team members pick a sticky note and indicate where they think it should go. For example, a team member might pick “All unit tests passing.” The team member says, “Our continuous integration system runs unit tests for every check-in and rejects any submission with a failing test.” Based on this, the team agrees to put that sticky note under the heading “Every Check-In.”
Another team member points out that exploratory testing is time consuming. They propose putting that sticky under the heading “Every Product Backlog Item.” After some discussion, the team agrees. This process continues until all the sticky notes have found a home. The team now knows how often they can reasonably meet the definition of done and thus create a new product increment.
Evaluating The Definition Of Done
If there are any sticky notes in the “Less Often Than Once Per Sprint” category, the team isn’t currently capable of meeting their definition of done every sprint. This represents a significant impediment for the inspect and adapt cycles of scrum. As a starting point, the team might start with a weaker definition of done that only includes the work that can be completed each sprint.
For the above exercise, the definition of done included work needed to be usable and available to stakeholders. If actually releasing the product requires more than pushing a button, then capture the work needed to release something new into to production. Put it on the wall and label it “Release Work.”
The more items of release work there are, the weaker the team’s definition of done is. Every bit of work needed to actually release the increment increases the cost and risk of releasing. This makes it harder for stakeholders to access the value of the product increment.
Evolving The Definition Of Done
The ideal is meeting the definition of done with every change and having the cost of release be almost zero. This allows the business to capture the new value quickly. The longer a team goes between increments, the more likely it is that trouble will happen. Problems found sooner are easier to diagnose and fix than problems that are found later. For example, a team that runs a full regression test at least daily will have a much easier time diagnosing and fixing the issues found, compared to a team that only runs regression tests weekly, monthly, or quarterly.
In pursuit of this ideal, the team will want to do work to remove things from “Less Often Than Once Per Sprint” and “Release Work.” Similarly, work will be done to promote things from “Every Sprint” to “Every Product Backlog Item” and eventually to “Every Check-In.”
Another reason that the definition of done evolves over time is that the team will discover weaknesses or gaps in their definition of done. For example:
- In a product backlog refinement session, the team might notice that a particular acceptance criteria is almost universal and so they add it to the definition of done.
- In sprint planning, the team might notice some vital work that isn’t currently captured in the definition of done.
- In the daily scrum, the team might surface impediments that could be avoided by a stronger definition of done.
- In sprint review, the team might discover missed stakeholder expectations and decide to add stakeholder sign-off or user acceptance testing (UAT) to the definition of done.
- In a sprint retrospective, the team might identify some ways a stronger definition of done might have prevented the introduction of bugs during the sprint.
Do It Early And Often!
If you are working with a new team, facilitating the creation of their definition of done should be one of the first orders of business. Don’t worry about getting it perfect or ideal; it’s more important that it be realistic. Then you begin the journey of evolving and improving the definition of done over time. If the definition of done is so weak that the team can’t create a usable increment at least once a sprint, then improving the definition of done should be a high priority.
More Thoughts On Done
Meta Note: Just as a team evolves their definition of done, I have evolved my approach to creating a definition of done. You can read my older thoughts in this article from 2018.
Cheers,