Often, people don't get the power out of a Definition of Done (DoD) that they really could. This article will review a few different thoughts on the DoD, relate the DoD to acceptance criteria, and show an example of a DoD. Hopefully, this will give you some ideas on improving your DoD so that it's not just a superficial checklist with little value.
In the 12 years that I've been a Professional Scrum Trainer through Scrum.org, I've taught many classes on Scrum and seen many misunderstandings related to the DoD. I've seen Scrum Teams that don't have DoDs and Scrum Teams that have such poor DoDs that they are not actionable.
During this article, we’ll look at some basics about the DoD. We’ll explore misunderstandings such as the application of the DoD, ways to use a fully achievable DoD and avoid creating a waterfall approach, when to inspect and adapt the DoD, and an example starting point for your DoD.
The formal description of the Definition of Done
First, let's look at what the Scrum Guide 2020 has to say about the DoD. That’s where the primary description of Scrum is kept.
The DoD is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog Item meets the DoD, an Increment is born.
The DoD creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the DoD, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the DoD for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a DoD appropriate for the product.
The Developers are required to conform to the DoD. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same DoD.
-Scrumguides.org accessed 01/05/2024
Does the Definition of Done apply to Product Backlog Items (PBIs)?
The DoD describes the state of the Increment when it meets quality measures. The DoD applies to the Increment, not directly to the PBIs. That seems contradictory to the following sentence that states when a PBI meets the DoD, an Increment is born. The development work may be complete for a PBI, but the Increment does not meet the DoD because other dependent PBI's must also be completed. For example, several PBIs relate to each other and must be integrated for a system test as part of the DoD. Such a situation can lead to a waterfall tendency, which should be avoided. In the vast majority of situations, the DoD applies to an increment, and a new increment does not exist until one or more PBIs meet the DoD.
The statements within a DoD must be achievable with a Sprint. Having a DoD with a statement that may take years, such as "completed clinical trials," isn't going to help. The PBI would linger for a very long time before being considered complete. However, having a DoD that says "updated clinical trial documentation and approach notes" with a follow-up PBI related to clinical trial completion might provide more value.
How do you start the Definition of Done?
The DoD starts with organizational standards that all teams must follow as a minimum. That infers that teams can add to the organizational DoD but cannot omit items from it. If multiple teams work on one product, they comply with the same DoD, but each team might have additional items in their DoD.
When do you change the Definition of Done?
The DoD should be inspected and adapted at the Sprint Retrospective. According to the Scrum Guide 2020, during the Sprint Retrospective "the Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their DoD." (Scrumguides.org accessed 01/05/2024) If you're inspecting the DOD, there's a good chance you'll adapt it too. The Sprint Retrospective is the right place and time.
I've seen plenty of situations where the DoD becomes stale and never changes. Often, it's because the DoD is so high level that once it's written, it never needs to change (e.g., coded, tested, and documented is all that's on the DoD). Don’t let this happen to you.
Here are some examples of adapting the DoD:
- There's a bug we are constantly encountering, but we can prevent it if we remember to test for it or inspect for it. Add it to the DoD.
- We need more formality around automated testing and integration so that we don’t miss some of it.
- There’s one statement that is frequently marked as not applicable. We should discuss removing it from the DoD.
If you decide to change the DoD during a Sprint, you may change the scope of the work and possibly affect the Sprint Goal. You should generally avoid changing the DoD during a Sprint, but there is a tradeoff. Pushing off the change to the DoD will possibly create technical debt. For example, you’re finding that many of the PBIs completed during the Sprint are using an outdated API. Adding the new API as part of the DoD would help to keep that from happening again and you should go back and fix the PBIs that are using the old API. If that puts the Sprint Goal in jeopardy, the entire Scrum Team should be involved in the decision to do this now or push it off until the next Sprint. It depends on the impact of the new API on keeping the Increment releasable and more.
What's the difference between DoD and acceptance criteria?
Acceptance criteria (AC) are not the DoD. The scope and intent of the two are different.
ACs are a construct typically associated with user stories – a specific type of PBI. ACs help to scope the user story by answering the question, "How do I know when I'm done?" and not to create test cases (although you can use AC to guide in creating test cases). An explanation of this nuance is beyond the scope of this document. Suffice it to say that if you have a user story with acceptance criteria, those ACs apply only to that user story. They're intended to help the Developers understand the user story. ACs also assume that the user story hasn't been completed yet.
On the other hand, DoD applies to every PBI – technically to the changes in the Increment that have been driven by fulfilling the PBI. The DoD can be thought of by saying "Don't forget to ensure," and the AC can be thought of by saying "Due to this change, verify that…."
Figure 1 The relationship between DOD and AC
For example, consider a DoD item such as
- use company colors
- use company fonts
- ensure the official company logo is included
A PBI about creating a login screen may have acceptance criteria such as:
- the password is masked
- only three attempts with bad logins are allowed before the account is locked
- you can reset the password without leaving the login screen
A PBI about selecting a report to print from a list of reports may have acceptance criteria such as:
- only one report can be selected
- the reports can be sorted by name and priority
- reports can be printed as PDF or PNG
Both PBIs must also use the company colors, fonts, and logo.
If something on a DoD doesn't apply it's OK to consider it not applicable (N/A). In the above example, a PBI that only results in communication between two systems doesn't need to consider company colors, fonts, or logos. A report that only prints in black and white doesn’t need to consider color. Keep in mind that if you see a lot of N/A entries, you may want to inspect the DoD during the Sprint Retrospective to determine if the entries should be moved to applicable PBIs from now on.
One way you can tie the DoD and AC together is that a DoD tacitly has an item that says “all acceptance criteria have been met” or the last AC in a user story is “complies with the DoD where applicable.”
Can I see an example of a Definition of Done?
Here’s an example of a DoD that can get the Increment as close to releasable as possible. Remember, this is only an example, not necessarily a DoD you can or should use blindly. Don't read too much into it. You have to think about your environment to determine what's right.
Figure 2 Example DOD based an example provided by Don McGreal
The “Organizational Standards” are what are adhered to for all of the agile teams. The "Team Extensions " exemplify additional items that a particular team has determined are appropriate. If you have more than one team working on a product, all teams conform to the organizational standards. Don't infer that the team extension items need to be technical. It just makes sense for this example.
Notice that certain items like "Beta Test Plans Updated” don't mean beta tests have occurred. "Outgoing Documents Updated/Notated" doesn't mean the outgoing documents are sent out or edited; they are just ready when the release time comes. Keep in mind that if you push off certain steps as per this example, you are creating a type of technical debt. Sometimes, like with clinical trials, you have to do this, but be careful to challenge yourself to make sure you must create this debt.
All items can be possible to complete within a sprint. Items such as "increase sales by 3%" won’t work. You may not know if the sales have increased for several months.
Notice that the items on the DoD example are all actionable and not high level as to be aspirational. It's not helpful to have items such as "tested, works as desired, meets the user need", which are wickedly vague. The items are actionable and binary - the increment either meets or doesn’t meet the DOD and it’s not a matter of someone’s opinion.
Conclusion
I’ve tried to clear up some misunderstandings with DoD. We've seen that the DoD applies to the Increment, not the PBIs, and the implications of that distinction are subtle. To avoid creating a waterfall approach, the DoD must be fully achievable within the time bounds of a Sprint. A DoD should be inspected and, if necessary, adapted at the Sprint Retrospective. Acceptance criteria apply to individual user stories, but the DoD applies to all PBIs. We have also seen an example of a DoD where a team has extended the organizational standards. Thanks to Don McGreal, Richard Hundhausen, and Hiren Doshi for their help on this blog.
If you’re interested in one of my classes, you can see them at www.suscheck.com.