Definition of Done in Agile: Ensure Consistency

I abhor half-done eggs. There is only done and raw. The Definition of Done in Agile helps to ensure the team’s delivery isn’t half-done. Like this inedible egg.

Agile’s Definition of Done

If you burn some free time searching for a definition for the ‘Definition of Done’ in Agile, you’re likely to find several variations. I found the most helpful to be Ilan Goldstein’s from his book Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips:

“The Definition of Done is a governing agreement that guides all developmental activities, clearly stating what is required for a piece of work to be categorically classified as ‘done’.”

-Ilan Goldstein

Kenneth Rubin’s book Essential Scrum: A Practical Guide to the Most Popular Agile Process also offers some helpful context:

“Conceptually the definition of done is a checklist of the types of work that the team is expected to successfully complete before it can declare its work to be potentially shippable.”

-Kenneth Rubin

I find the phrase ‘type of work’ to be a bit questionable but otherwise agree with the sentiment. Essentially, the definition of done is a checklist of the steps to follow to ensure that the development team produces consistent work.

You’ll want to be careful not to confuse the Definition of Done with acceptance criteria, as even the literature often conflates these two terms. This lack of clarity was one of my complaints against the ICP-APO course I took.

It’s also helpful to note that DoD has become a common shorthand for “Definition of Done.” I’ll likely use this shorthand throughout the rest of this article to alleviate my fear of improperly capitalizing the complete phrase.

Definition of Done Benefits

Improved Accuracy in Sprint Planning

How would you respond if I were to ask you how many cheesecakes you can bake per day? Go ahead and think about it for a moment. I’ll be over here humming the Jeopardy music while I wait.

You may reason that it’s common practice to define a “day” as eight working hours. A quick google search might uncover that a cheesecake should bake for roughly one hour. With that basic information, one coule bake about eight cheesecakes daily.

But did you consider quality? What about context? Perhaps I’m asking you about these cheesecakes because we’re going to open an online cheesecake bakery. Each type of cheesecake must go through a photoshoot before being posted on our website. Also, each fourth cake needs to go through a quality check (I’ll eat said cake and give a thumbs up or down).

How does this information change your original estimate? I’d wager your guess is starting to dwindle.

The authors of Head First Agile made an excellent point about the role of DoD in Sprint Planning. The team must agree on what it means for an item to be done before they can arrive at a reasonable amount of work to pull into their Sprint Backlog.

Eight user stories could quickly dwindle to five, just as your cheesecake estimate. The definition of done can help us realize this reality in Sprint Planning vs. the end of the Sprint when it becomes apparent we’re going to miss our Sprint goal because we hadn’t considered all of the work needed to reach the ‘potentially shippable’ goal.

Increased Transparency

I’ve discussed transparency in a previous article. The DoD will help to increase transparency by combating the “dev complete” mentality.

Somewhere over the years, a phenomenon occurred where developers started referring to work as “dev complete.” This in-between status intends to represent the state where the developer assumes they’re done, but someone must confirm this assumption via testing. It’s common to have other ancillary tasks that also must occur before the team can release the code to production. Dev complete really means it’s not done.

By consistently following a DoD that establishes the qualities work must conform to before we say it’s “done,” you’ll increase transparency by decreasing obfuscation. If work is done, we say it’s done. If it’s not, we won’t refer to the state of the work in terms that a stakeholder might misconstrue as being done.

Avoiding “Works on my Machine”

Another familiar phrase developers might utter is “works on my machine.” This idiom is a lousy response to a situation where the live product isn’t behaving as expected.

Your DoD should incorporate the testing and release steps required to reduce, if not prevent, these situations.

Protects Trust

I used to be so bad at not showing up on time that my friends started referring to any ETA’s as “Miranda Time.” As in: “She said she’d be here around 6 PM, but that’s Miranda time, so don’t expect her until at least 8 PM.”

When a team continuously communicates that work is done, only for the stakeholder to learn it doesn’t meet their expectations for quality or completeness, this erodes trust.

With a standard DoD, we have something to refer to that ensures a shared understanding of what is meant by ‘Done.’

When used in conjunction with acceptance criteria, the definition of done can increase customer satisfaction.

Ensures Consistent Quality

The DoD commonly includes the testing types expected to be completed and passed. When everyone follows the same process to test changes, consistency will increase.

Applying testing consistently to all stories that pass through a Sprint ensures the stability of the product we’re developing by targeting a consistent level of quality.

Each organization may have different testing requirements. Once agreed-upon quality measures are defined, the DoD helps Scrum teams apply those requirements consistently to all Product Backlog Items.

Ensures Potential Shipability

The Scrum Guide tells us that each Increment should be potentially shippable.

Your DoD should include the steps necessary to ensure each unit of work contributes to the overall Increment and doesn’t leave a bunch of additional work unaccounted for that the team will need to complete to ship the product.

If we lack documentation, approval steps, or smoke testing that might need to occur after a story passes testing, we’re still not done. We should include this work in Sprint Planning and not be surprised by it at the end of the Sprint.

Sets the Focus

Most everyone will have heard the fable of the tortious and the hare. The hare gets arrogant and assumes he’s got the race in the bag, so he stops to take a nap. While he’s sleeping, the tortoise plods along and wins the race.

The hare lost sight of what winning was. We don’t want to be like the hare. We don’t take our foot off the gas when we’re “dev complete” or even “QA complete.” The Scrum team isn’t done until they’ve completed everything on the checklist, which could include several steps beyond QA, depending on their company’s needs.

Works Consulted

• Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips
• Essential Scrum: A Practical Guide to the Most Popular Agile Process
• Head First Agile: A Brain-Friendly Guide to Agile Principles, Ideas, and Real-World Practices
• Agile Product Management with Scrum: Creating Products that Customers Love
• Agile Game Development with Scrum
• Scrum Guide
• There’s Value in the Scrum Values
• Understanding Scrum Values: Openness
• There is No State Called “Dev Complete”
• Why You Should Never, Ever Use The Phrase: “But It Works On My Machine”

TLDR

I want my eggs to meet my definition of done, which includes that all eggs are cooked-hard. If you want your team’s code to meet stakeholder expectations without re-work, the proper creation and usage of a definition of done can facilitate that. If you’re one of the weirdos that like runny eggs, your DoD differs from mine - but you still have one.