In today's blog, I want to talk about the evolution process of the Scrum Team's Definition of Done and explain a simple technique that I find very useful in helping a Scrum team managing their Definition of Done.
Core Purpose of Scrum
If Scrum were to be reduced to one purpose and one only, it would be the creation of a "Done" increment. Why is this so important? Because a "Done" increment provides transparency for everyone to inspect the increment and adapt the Product Backlog accordingly. This process is essentially your gateway to agility.
One word to summarise Scrum? Empiricism. - Gunther Verheyen
Definition of Done
When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. The Scrum Team must have a shared understanding of what it means for work to be completed to ensure transparency. This is the Definition of "Done" (often abbreviated as DoD) for the Scrum Team and is used to assess when work is complete on the product Increment.
The DoD is mentioned in the Scrum Guide as an artifact of transparency.
DoD in real life
Although the DoD serves as a crucial part of Scrum, it is also often neglected by many Scrum teams. I'll give you a few examples:
- Not having a DoD. If this is the case, continue to read this blog and start creating one ;)
- The team has a DoD, but it was written a long time ago. It is not a living artifact.
- The team is not owning the DoD and implicitly also not owning the quality.
"As Scrum Teams mature, it is expected that their definitions of Done will expand to include more stringent criteria for higher quality." - Scrum Guide 2017
- The DoD is stored somewhere on Sharepoint, Confluence or even printed out and attached to the Development Team's taskboard. The team know they have a DoD, but it's not visible, and we're not 100% sure what's in our current DoD.
Lack of Empiricism is often the main driver
It all comes down to the fundamentals of Empiricism. Low transparency (DoD not visible, for example) results in the team not inspecting the DoD adequately, which ultimately leads to failing to adapt the DoD as more is learned continuously.
DoD EvoCycle Technique
When it comes to helping teams take ownership of the DoD, I've find the following technique, which I call the "DoD EvoCycle" (short for Evolution Cycle) pretty effective.
Prerequisite:
- Enough space on the wall to create four columns. Don't name the columns yet as this can influence or limit the thinking process of the team.
- Enough post-its and pens
- Happy and energetic people goes a long way ;-)
Step 1 - Think big, the sky is the limit:
The first step is to encourage the team to think big. I often use the following invite:
"List all the things that need to be done/checked/marked before the PBI or Increment can go live. Both inside and outside out influences, the sky is the limit."
When finished, ask the team to place all the items in the first (furthest left) column.
Tip:
- Write each item on a post-it as clear and concise as possible.
- Check out Liberating Structure as some methods can help your team address the invite I mentioned above.
Step 2 - Within our self-organizing ability?
The second step is all about figuring out what's within the team's self-organizing ability. The invite I use here is:
"Of all the items in the first column, which ones are within our self-organizing ability? Meaning we don't need anyone/anything outside our team to do this?"
Ask the team to move these items from the first column to the second column.
Tip:
- Watch out for items such as "getting approval from someone or a department outside the Scrum Team". Remember, this technique is about identifying all things in/outside the Scrum Team from a self-organizing point of view. So in this case, the getting approval item moves to the second column, but a new item (doing it yourself) needs to be created and placed in the first column.
Step 3 - The "ugly" truth
The third step leans on the Scrum values of Openness and Courage. Be courageous and open to identifying which items are in our self-organizing ability, but we're not doing it at this moment.
Ask the team to move these items from the second column to the third column.
Tip:
- It's about identifying the items, so don't get tempted to go into solutioning mode or to justify why this item isn't being picked up.
Step 4 - Definition of Done in the making
The last step is to look at the DoD items in the first and second column and identifying items the team is already doing. Move these items to the fourth (right) column.
Advantage of this approach
By now, you should have a nice visual overview of your team's current state when it comes to the DoD. You can see what's currently in the DoD, what is inside their ability but not picked up yet and what is outside their field of influence. At this point, it's good to verify with the team if they also see the same pattern. If yes, then add the names of the columns to enhance more transparency.
Release throughout the Sprint
One of the misconceptions about Scrum is that releases are done only at the end of the Sprint.
"The Scrum Framework actually encourages teams to improve their process, infrastructure and practices to the point where releases can be done throughout the Sprint." - The Liberators
As teams improve their process, items on the DoD EvoCycle Board will gradually move from left to right. Some items will move quick, while other items goes slower as it impact
Summary
When it comes to helping the team creating a DoD, I find this technique pretty useful. The DoD EvoCycle visualize the team's DoD by showing the entire evolution in one overview. This makes it easier for the team to discuss their current DoD and which DoD item should/can be included next to make the DoD stricter for higher quality.
When all DoD items are moved to the right, it implies that the Scrum team can deliver value without any outside help. Just imagine how awesome that would be! :)
