Definition of Done: Anti-Patterns

When your exercise bike is a clothes rack, you don’t question why the pounds aren’t melting off. The definition of done is also ineffectual if misused.

Common Definition of Done Pitfalls

Being familiar with the common definition of done anti-patterns will go a long way toward helping your team avoid them.

Lack of Continuous Improvement

The ‘set it and forget it’ strategy only works in limited situations, and agile approaches take the opposite stance. Empiricism dictates that we need to revisit our current state frequently to determine what recent learning we can apply to our processes with the goal of continuous improvement. Teams should revisit their definition of done, add new items and remove outdated items.

In his book Agile Game Development with Scrum, Clinton Keith states:

“Teams expand the standard DoD by improving their practices. This enables the team to continually improve their effectiveness.”

He isn’t the first one to take this stance. The Scrum Guide recently added the definition of done as one of the elements that should be inspected and adapted during the Sprint Retrospective.

“The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.”

-Scrum Guide

Agile implementations don’t happen overnight; you can’t just flip a switch and be agile. Organizational impediments - which can be slow to resolve - might block some elements that you’d like to be in your definition of done.

Kenneth Rubin agrees in Essential Scrum that removing organizational impediments is another reason to revisit and evolve your definition of done.

“For some, real impediments might prevent them from reaching this state at the start of development, even though it is the ultimate goal. As a result, they might (necessarily) start with a lesser end state and let their definition of done evolve over time as organizational impediments are removed.”

-Kenneth Rubin

When teams fall into this anti-pattern and let their DoD become stale, they risk quality reduction, lack of consistency, and displeased stakeholders. To prevent this, ensure that your team sets assign recurring time to review and update your agreement. The retrospective meetings are a perfect opportunity for this.

Copying from Someone Else

It can be daunting to start with a blank screen when trying to develop your team’s DoD. There isn’t a template that teams can use to jump-start the process. Although it might seem logical to look at examples from other groups for inspiration, be cautious about piling on steps that don’t apply to your team.

I have a friend who always has to order last. She has FOMO (fear of missing out). She doesn’t want to miss the sensational experience of a meal better than the one she selected. She sometimes even incorporates elements from multiple orders to compose the ultimate meal. She’d get the salad as Ron, but with the garlic bread from Hermione’s pasta.

This approach has three main risks:

1. One size doesn’t fit all

Everyone doesn’t share the same preferences and capabilities. I’m not too fond of those crunchy strips that they sometimes put on a salad, and we’re pretty sure that I have a least a slight shrimp allergy. Ron’s salad may not be an option for me.

This logic also applies to the DoD. Each element should serve a purpose, and we should do our best to ensure we don’t add something that would harm our team.

These agreements can be pretty specific to a given team’s situation. Generally, the DoD is built slowly over time, and the team adds items to prevent specific circumstances from reoccurring. One team’s DoD may be entirely irrelevant for a different team.

2. Franken-DoD

Salad and garlic bread can make an excellent pairing, but some pairings won’t work as well. My friend is diligent about pairing the foods in an appetizing way. After all, who wants to eat fish and chocolate?

Similarly, we want the DoD to be a living document that is cohesive and organized in a way that makes sense. It can quickly lose its usefulness if we construct it by taking bits and pieces from here and there.

Before adding a new item, the team should ensure that they word it in a way that is cohesive with the rest of your agreement and doesn’t throw off the feng shui of the document.

3. Overload

My friend is a slim lady. If we’re out with eight friends, she isn’t able to cobble together a meal that incorporates elements from each of the dinner guests. If she attempted to order this way, she wouldn’t possibly be able to consume that much food, and portions of her order would go to waste.

The same logic applies to the definition of done. We can’t just keep stuffing tasks onto the list; eventually, it will be ripping at the seams. This topic is important enough to warrant a separate section, so we’ll cover that next.

Overly Ambitious

Regardless of its contents, having a DoD is better than not having one. Don’t get so hung up on trying to throw everything of any slight value into your DoD. As your agreement approaches larger sizes, it will lose rather than gain usefulness.

If your DoD becomes so long and complicated that people can’t quickly reference it, no one will use it.

Ilan Goldstein shares similar thoughts in Scrum Shortcuts without Cutting Corners:

“To compile an initial DoD, I recommend that you start extremely realistically or perhaps even conservatively.”

You want the agreement to be something people can quickly reference as each Product Backlog Item goes through the various stages from backlog to done. The more unwieldy the thing is, the less likely people will use it.

This anti-pattern can lead to the team moving further and future away from reading a potentially shippable product increment at the end of the Sprint as they rely less and less on the guidelines defined by their DoD.

Out of Sight, Out of Mind

My husband struggles with diabetes. Mostly he endeavors not to consume the chips left on the kitchen counter. So every morning, while I’m cooking my breakfast, before everyone else in the house is awake, I put all of the chips back into the kitchen pantry. Now, if my heart-mate wants to consume death chips, he at least has to think of it on his own and go through the effort to search for them in the pantry.

Unlike chips, the DoD is healthy for the team to utilize. We don’t want to make it hard for them to access this resource. Back before the world went remote, some groups used to post their DoD in the workspace, where it was easily visible to everyone. In this new world of remote work, it might be harder to accomplish this same feat, but you should encourage the team to think of ways to keep the DoD front of mind.

When talking about the Scrum value of commitment, Gunther Verheyen indicated that the Development Team should commit to the definition of done. Don’t have the team spend time collaborating with stakeholders to develop this checklist just for shiggles. The team must be committed to using the DoD to ensure consistency and quality.

This anti-pattern is doubly wasteful as we’ve created something that we’re not going to use and waste our time doing so. Also, the team is missing out on a valuable tool that should be an excellent resource.

Lack of Collaboration

Another anti-pattern in developing the definition of done is generating the list in a vacuum. The team should seek feedback and collaboration from stakeholders when creating the list of tasks they intend to apply to every user story.

Don’t forget to involve the whole team as well. The team should involve the Product Owner and Scrum master if doing Scrum.

You don’t need to schedule a meeting with 200 people. If it works more for your situation, you can develop the document iteratively, adding to it as you have discussions with each stakeholder.

When agile teams develop the DoD sans collaboration, it doesn’t help build a common understanding between stakeholders and the team regarding what to expect when the team says a user story is done.

Works Consulted

• Empiricism in Scrum: Rational Decision Making
• Agile Game Development with Scrum
• Scrum Guide
• Essential Scrum: A Practical Guide to the Most Popular Agile Process
• Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips

TLDR

If you want to reap the benefits of your exercise bike, keep it unobstructed and use it regularly. If you’re going to reap the benefits of your definition of done, keep it simple and update it in collaboration with your team and stakeholders.