Definition of Done - The What and Why and How to Grow One

Team Management

Agile 101

Definition of Done – An Overview

When you look at the cards in the Done column of a Kanban or Scrum board of a development team, can’t you help but wonder what hasn’t yet gotten done? After all, a software product isn’t just about the code. If that sounds familiar, you’ll benefit from a Definition of Done. DoD for short. Let me walk you through what you need to know.

What Is Meant by the Definition of Done in Agile?

In Agile, you use a Definition of Done to say what you’ve done to what standard of quality when you declare something done. In more concrete terms, it lists the criteria you’ll meet before you claim a user story or a bug report can be shipped (released) to your customers. You may be asking yourself what the difference is with Acceptance Criteria that also specify the criteria you need to meet to implement a user story or fix a bug.

Battling It Out: Definition of Done vs. Acceptance Criteria

It’s a matter of scope and focus.
  • The Definition of Done applies to all your work. Acceptance Criteria only ever apply to a single item on your backlog.
  • The Definition of Done clarifies what you do as a team. Acceptance Criteria clarify what the product does — its functionality.
  • The Definition of Done can contain criteria for “non-functional” aspects and cross-cutting concerns. Acceptance Criteria talk of functional aspects of a single item of work. You’ll only rarely find non-functional aspects in them. And when you do, they just list the exceptions to the general non-functional requirements, making these more strict or lenient for that work item.
Now that’s cleared up, here’s why you want clarity and transparency on what you do as a team.

What Are the Top 5 Benefits of a Good Definition of Done?

Dod
The benefits of creating and using a good Definition of done are:
  • Transparency of responsibilities
You know what you need to do and understand what you do not need to do. For example, you know it’s your job to implement correct behavior, but creating training videos is not. You’ll become more predictable in what you deliver.
  • Realistic Sprint Commitment
With an itemized list of exactly what you need to do to get to done, you’re better able to assess how much you can realistically take on in a Sprint. You’ll become more reliable.
  • Reduced risk of rework
Checklists work. Aviation wouldn’t be as safe without them. When you reduce the work left undone when you declare something done, it means less (risk of) rework later. You’ll become more efficient.
  • Higher quality, less effort everywhere
As you mature in your development practices, you’ll raise the bar on the quality you deliver and reduce other staff’s workload. For example, fewer escaped bugs mean lower demands on support staff. You’ll deliver better quality and help your company become more efficient.
  • Predictability and Sustainable Pace

Fewer escaped defects means you can create value with the whole team instead of having to divert some of you to resolve bugs. You’ll become more productive and predictable, and get to work at a constant sustainable pace.

All this helps raise the confidence a team feels in delivering valuable software and grow the trust other teams and stakeholders will place in a team.

But don’t get carried away just yet. There’s a catch.

How Not To Benefit From a Definition of Done

Definition Of Done
Like with everything worth having, you only get the benefits if you avoid the common mistakes.
  • Out of sight, out of mind
Having a digital DoD somewhere means you’re not likely to make it a priority. Not on purpose, but because there are so many things clamoring for your attention.
  • Too much too soon
Putting all your aspirations in your DoD means you’re unable to achieve much of it. That’s no fun. You’ll avoid it or treat most of it as optional, which detracts from its importance. I’ll bet you’re wondering what you can do to avoid these traps.

How To Create and Adopt a Definition of Done Successfully

Adopting a Definition of Done requires a behavior change, a change in habits. To be successful, you’ll want to treat it as such. The trick is to keep it top of mind, make it easy — and fun — to do, and to reinforce it until it’s become an established practice. So, what’s the solution?

How To Create and Grow a Definition of Done

Well, let’s break it down:
  • Keep your newly minted Definition of Done in full sight at all times. Hang it on every wall, tape it to the inside of the bathroom doors, hang it at the coffee counter, etc. You want it hard to miss and forget.
  • Refer to your DoD often during meetings. Make it a natural topic to discuss when aligning on progress, reviewing work, and planning what comes next.
  • Make your initial Definition of Done short and sweet, and easy to meet. You want easy wins at first. Even with a simple “Yes!” celebrating each of them is crucial in establishing new habits.
  • Only raise the bar when you’re meeting your DoD consistently and reignite celebrations (if you let them slip) when you do.

Not too tricky, right?

But, I bet you still have some questions. Like, who writes or defines the Definition of Done, or when is it most appropriate for a development team to change the definition of done, and what to put in it.

Who Writes or Defines the Definition of Done

The Scrum Guide says: If “Done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done”. And: The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. From that, it’s pretty clear that a Development Team decides their DoD. Not the Product Owner, not the Scrum Master, not a Project Manager, not the Development Manager, but the Development team. You want to define your DoD before working on a product as a team (or you risk not doing it at all). But when do you update it?

When To Change What’s in a Definition of Done

Kanban Team
Many will say, “in a retrospective.” But Retrospectives are meant to deal with more than the actions to complete a work item. What’s more, your Definition of Done serves as your quality checklist. That makes it a continuous improvement effort that merits its own improvement cycle. And remember, a change is not necessarily an improvement. Putting an action from a Retrospective straight into your DoD can mean you’ll be changing the DoD more often than is wise. Frequent changes — especially taking out what you added not too long ago — decrease the perception others have of your reliability. So, wherever your points for your DoD come from — a Retrospective or some other effort for improvement, test them out first. Tweak and adjust until they deliver what you aimed for. Now, let’s see what’s in a good DoD.

Example of What Is in a Good Definition of Done for a Development Team

You customize a good Definition of Done to the maturity of your development practices. So I’ll give you the basics and follow it with what you can add as you mature.

The Very Basic Basics

  • Implementation evaluated by a second pair of eyes? Peer reviewed or pair-programmed.
  • All Acceptance Criteria met?
  • Code integrated (merged)?
  • No known defects?
  • Monkey tests executed?
  • User Guide (customer documentation) updated or input provided to others?

Code Quality

  • Compilation error, warning, and hint free?
  • Coding standard followed?
  • Static analysis metrics at or above target?
  • Dependencies minimized?
  • Code refactored to meet SOLID and other code design principles?

Staging

  • Integrated build error, warning, and hint free?
  • Smoke test passing?
  • Package creation error, warning, and hint free?
  • Package deployed to the test environment(s)?

Functional Regression Tests

  • Every item in Acceptance Criteria covered by at least one acceptance test?
  • Unit tests passing?
  • Integration tests passing?
  • Functional or system tests passing?
  • Acceptance tests passing?
  • Tests executed on all supported platforms?

For all automated tests:

  • Coverage on or above the norm? (For example, 85%.)
  • All new units / integrations / functionality covered by tests?
For legacy systems (applications where automated tests do not cover large chunks of codes):
  • Golden Master updated with scenarios for updated and new functionality?
  • No differences or only predicted differences when comparing results from Golden Master test data from current production code and
That’s a lot, right? And following CI/CD and DevOps practices can add even more. But I’m sure you get the point and can take it from here. And…

Get To Done on Your Definition of Done

You can put a stop to feeling uncertain now. You know everything you need to know about a Definition of Done to make it work to your advantage. To be confident that when a card is in the Done column, you’ve indeed completed all the work, and its quality is as high as you’re currently able to achieve. So, take the first step. Get your team together and create your first Definition of Done version.

Signup for updates!

Medha Case Study

Check out Nimble Now!

Humanize Work. And be Nimble!

Free Trial