The core responsibility of a Scrum team is to deliver a done, useful, and valuable increment every Sprint. A couple of years ago, Christiaan Verwijs and I created the “Definition of Done exercise” for the Scrum.org Professional Scrum Master II class to make transparent what this means, and what happens when teams are unable to do so.
With this exercise, Scrum teams create transparency around their ability to deliver completely “Done” products every Sprint. And if they can’t, it makes painfully clear how risky that really is. Without a Done increment, predictability suffers, and the risk of persistent impediments increases.
In this blog post, I’ll offer a rough outline of the exercise and its key takeaways. Most importantly, I’ll describe a change I recently made. It might seem like a minor difference, but in terms of limiting risk and increasing predictability, it can make a huge impact!
The flow of the exercise
Below I’ll share a rough overview of the steps I use whenever I run the Definition of Done exercise. I won’t describe it in full detail, the (digital) exercise already contains a step-by-step explanation.
- Step 1 — Clarify the purpose of a Scrum team. Ask the group to summarize the purpose of Scrum in a oneliner. Ideally, the result is something like ‘create a useful, valuable, done increment each Sprint’.
- Step 2 — Introduce the ‘Levels of Done’ cards. Invite the group to order the ‘Levels of Done’ cards. Emphasize that this is a rough representation of the workflow that most items in a Sprint Backlog go through during a Sprint, preferably one by one.
- Step 3 — Distribute the ‘Aspects of Done’ cards. These blue cards contain examples of ‘rules’ that teams can have on their Definition of Done and that represent work that happens in the Sprint.
- Step 4 — Distribute the ‘Problem’ cards. These red cards represent unexpected problems that may emerge that may be discovered somewhere as the work on an item is being done. For each problem, the group connects the ‘problem’ cards to the workflow phase where it’s most likely to be detected.
- Step 5 — Discuss patterns and impact. With the patterns of ‘rules’ and ‘problems’ cards visible, you can now debrief together what this means about your work together. And more importantly, the risks and unpredictabilities that are inherent to that work.
- Step 6 — Clarify where Scrum starts. The Scrum framework only reduces the risk of complex work when teams can at least deliver a releasable, Done Increment every Sprint. Anything less isn't Scrum and won't help your Product Owner and stakeholders to reduce the risks of the investments they're making with their time and money.
When is the product increment really “Done”?
As mentioned before, the Scrum framework requires a useful, done, and valuable increment at least once every Sprint. Only then can a Scrum team truly validate underlying assumptions with their stakeholders. Each increment represents a step toward achieving the larger Product Goal.
When a Scrum team considers ‘releasable’ the ideal end state of their Definition of Done, they still face a substantial amount of risk and uncertainty.
What if the product increment…
- The product increment takes weeks or even months before it is actually released to production;
- The product increment can’t be deployed because of a breaking bug;
- The product increment fails to deploy to production due to missing software on the production servers.
These are some examples of risks you’ll only detect by releasing the product increment. And even when a team considers the product increment ‘Done’ when it’s released to production, risks, and uncertainty aren’t limited to zero.
Some real-life examples of problems we experienced with Scrum teams after releasing to production are:
- Stakeholders complain because a critical element of the product increment hasn’t been implemented;
- The new product increment turns out to be impossible to use by people with impaired vision;
- Users are frustrated about the new product increment because it uses terminology that is very different from what they’re used to;
- Users are disappointed because the new feature only causes rampant performance issues;
- Stakeholders are unhappy because the new feature doesn’t solve the problem they thought it would.
Limiting risk to zero is probably impossible. But all these examples could have been detected earlier when a Scrum team considers a product increment ‘Done’ when they not only release the increment but also validate its value during the Sprint.
This validation of the value should take place with real stakeholders and real users. By real stakeholders, we mean people with an actual stake in the product. So, not people with an opinion about your product, that’s what we consider your audience. But people have sleepless nights when the product doesn’t live up to their expectations. Real users — not a test group with a bunch of fake users — are people that actually use your product frequently. Involve those people during the Sprint to validate the value you hope to deliver with a new product increment.
As your Definition of Done becomes more comprehensive, the chance of unexpected problems showing up decreases. Limiting risk to zero is probably impossible, but when you expand your Definition of Done to ‘Validated Value’, it will definitely improve quality, and predictability and lowers risks.
Imagine ‘Validated Value’ as a phase next to ‘Released’. When you expand your Definition of Done to ‘Validated Value’, it will definitely improve quality, and predictability and lowers risks.
Learn more
If you’re interested in learning more about the Definition of Done and/or finding your real stakeholders and users, check:
- The blog post ‘Why Scrum Requires Completely “Done” Software Each Sprint”;
- The three do-it-yourself workshops we created to start using a Definition of Done, improve it, or take it to the next level;
- An experiment to help you find your stakeholders.
Closing
In this blog post, I described how to take your Definition of Done to the next level, and how validating the value of the Scrum team’s work during the Sprint limits risk and increases predictability. Why don’t you give this exercise a try with your team? Make the current state of your Done of Done transparent, and work together to identify and implement improvements.