DoD EvoCycle 2.0 - A Simple Technique to Effectively Manage your Definition of "Done"
A couple of months ago I wrote a small blog about the 'DoD EvoCycle'. A simple technique that I use to help the Development Team take ownership of managing their Definition of "Done." Recently, I did a small change to make it simpler and more intuitive. Would like to share this and hope you'll find it useful as well 🤗
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 - 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
- The DoD is stored somewhere on Sharepoint, Confluence or even printed out and attached to the Development Team's taskboard. The team knows 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 found the following technique, which I call the "DoD EvoCycle" (short for Evolution Cycle) pretty effective.
- 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 activities that need to be done/checked/marked before the PBI is considered done so that the Increment can go live/production. Both inside and outside out influences, the sky is the limit."
When finished, ask the team to place all the items on the wall.
- Write each item on a post-it as clear and concise as possible.
- For step 1, I find the Liberating Structure 1-2-4-ALL pretty compelling here.
Step 2 - Outside vs inside the team's self-organizing ability?
The second step is to identify which items are outside and which items are inside the team's self-organizing ability. The invite I tend to use here is:
"Of all the activities mentioned in step 1, which ones are outside, and which ones are inside the team's self-organizing ability?
- For this step, I tend to do it planar, but feel free to use a different kind of technique to increase maximum engagement.
- Occasionally you'll bump into activities where it's not clear whether this is inside or outside. Mark these activities as "Unknown for Now."
- At this stage, it's good to have the definition of self-organizing clear.
"Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team." - Scrum Guide
When finished, place the activities that are outside the team's ability onto the first column and name this column "Outside".
Place all the activities that are identified as inside the team's ability onto the second column. Name this column "inside".
Step 3 - Definition of Done in the making
If you've reached this step, you should by now have two columns displaying activities that reside outside and inside the team's self-organizing ability. Congratulations, you're almost there!
The last step is to look at the two columns and identify which items the team is already doing. Move these items to the third and final column.
- Often activities in the first column (outside) will take longer to address compared to the activities in the second column.
- Make sure you have your DoD EvoCycle transparently displayed so that the Development Team can continuously inspect and adapt their Definition of Done.
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 quickly, while other items go slower as it impacts the organisation.
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! :)