Experiment: Evolve Your Definition Of Done

A working, ambitious Definition of Done can be a powerful tool that guides you toward shipping fast.

In our book, the Zombie Scrum Survival Guide, we explore what causes Zombie Scrum, which looks like Scrum from a distance but lacks a beating heart. We also offer 40+ experiments to recover from Zombie Scrum, one of which is this experiment.

Your Definition of Done is the set of rules that the implementation of every Product Backlog Item has to conform to for it to be considered “Done.” It reduces rework and quality issues by setting clear goalposts around what quality and professionalism mean to your work. There are three steps to using a Definition of Done successfully:

1. Having a Definition of Done
2. Using a Definition of Done
3. Gradually evolving your Definition of Done to make it more professional

If you don’t have a Definition of Done or don’t use it, you will have to take care of that first. After that, you can gradually expand it to ship faster.

Required skill

The experiment is simple. However, creating transparency around your deployment process might be challenging.

Impact on survival

A working, ambitious Definition of Done can be a powerful tool that guides you toward shipping fast.

Steps

To try this experiment, do the following:

1. Gather your Scrum team and familiarize yourselves with your current Definition of Done. Make sure it accurately represents what you are currently doing. A good opportunity is to do this periodically during a Sprint Retrospective.
2. Ask, “If we wanted to release immediately after a Sprint, what rules should be added to our Definition of Done to ensure a high-quality result?”. What checks would be necessary in addition to the current Definition of Done so that each Product Backlog Item, and the Increment as a whole, is “Done” to the extent that the Increment can be released immediately after the Sprint? Include even the rules that seem completely infeasible now but are vital to guarantee high-quality releases. Collect the additional rules on a second list.
3. You now have two lists: your current Definition of Done and a list of rules you still need to be doing or are not yet capable of. The second list represents the gap between what you are doing now and what is necessary to truly reduce the risk of complex work (see Chapter 5). Each item on that gap list would take away or reduce a risk that is present today. The more significant the gap, the more risks you accept, and the more work will be needed. Most Zombie Scrum teams start with a big gap. In a heavily zombified environment, the best strategy is to broaden your Definition of Done by making small improvements instead of going for massive shifts.
4. Ask your team, “What would be our first step towards being able to release immediately after the Sprint?”. What can your team do right now without needing approval or resources they don’t have access to? Who needs to be included? Where can you find help and support? The experiments “Take The First Steps to Automate Integration & Deployment” and “Ship Every Sprint” help when your team is struggling. Make sure to come up with specific, actionable steps like automating certain tasks or involving people to broaden your Definition of Done.
5. Add one or two action steps to the Sprint Backlog of upcoming Sprints. Keep your Definition of Done and the gap list visible in your team room. Collaborate with stakeholders about your Definition of Done and your gap list. They are your natural allies. An expanding Definition of Done increases quality and allows them to receive value sooner. Continuously ask: “What creative solutions can we find to include items from our gap list into our Definition of Done and prevent the associated risks?”.

An expanding Definition of Done increases quality and allows them to receive value sooner.

Our Findings

• Break more significant improvements into items you can accomplish within a Sprint. It is more helpful to take several smaller steps than one giant leap.
• Suppose you are already able to release immediately after a Sprint. In that case, you can make your experiment more ambitious by asking your team to consider adding rules or steps that improve your ability to release individual Product Backlog Items during the Sprint.
• Make sure your improvement activities align with your business needs. Dedicate large portions of a Sprint to improvement only when everyone on your Scrum team and stakeholders is on board.

Looking for more experiments?

Aside from a deep exploration of what causes Zombie Scrum, our book contains over 40 other experiments (like this one) to try with your Scrum team. Each is geared towards a particular area where Zombie Scrum often pops up. If you’re looking for more experiments, or if these posts are helpful to you, please consider buying a copy.

Order your book directly from us for some nice extras.