The Definition of Done (DoD), Explained

In Agile and Scrum, where work is done incrementally and iteratively, the Definition of Done (DoD) gives the criteria for when a piece of work can be deemed complete and the team can move on to the next items in the backlog.

In this post, we’ll take a deep dive into the DoD, examining its definition, its purpose, and the right approach to its creation. We’ll also look into a few practical, real-world examples to help you put it all together and give you inspiration for creating a DoD for your team.

What is the Definition of Done (DoD)?

Let’s start with the basics:

The Definition of Done (DoD) is the criteria that must be met for the work on a backlog item — an epic, an enabler, a story, a task, or any other type of item used by the team — to be considered complete.

The DoD is the documented, agreed-on definition and shared understanding within the Scrum team of what it means for a piece of work to be “done.” It serves as a clear, non-negotiable standard for the members of the team, which ensures that everyone is working towards the same level of quality.

Most Scrum Teams document their DoD in the same place where they’ve documented the rest of their working agreements. This can be a folder, a wiki space, or any other way the team and organization use to document and manage knowledge. As a minimum requirement, this place must be accessible to and known by all members of the team.

How is the Definition of Done (DoD) created?

The Definition of Done (DoD) should be an internal agreement of the team, not something that’s imposed on them externally or from high above. The team should come together, chew on it a bit, figure out what makes sense for them, and then write it down in a clear and straightforward fashion.

Once the DoD is down on “paper,” it can start to serve the team — and all developers on the team are accountable for following it. If the DoD is lacking something or part of it isn’t creating value for the team, then they can discuss that in the Sprint Retrospective and move towards revising it.

How does the Definition of Done (DoD) improve the team’s work?

The Definition of Done (DoD) sets the standard for what is considered “good enough” by the members of the team. Basically, it serves as a benchmark against which completed work can be measured. This ensures that the team is not wasting time on rediscovering fire and reworking unfinished work falsely considered or misrepresented as done.

It’s the shared agreement that gets everyone’s outputs to the same level of completion, regardless of which developer worked on a given product backlog item and what circumstances that work took place under.

Why even have a Definition of Done (DoD)?

It’s a good question. To help you come to the answer why the Definition of Done (DoD) is needed, allow me to paint a picture for you:

Imagine Olympic sprinting without a finish line. None of the sprinters will know when exactly to stop. Some will fool themselves that they are done sprinting when they really aren’t. Some will fool others. In the end, nobody’s a winner because winning a game is impossible without a definition for how to win it.

The DoD does the same, but for the team. It sets an explicit, unambiguous definition for when a backlog item can be considered “done” so the developers working on it — and the team as a whole — can move on to everything else. It’s the same as the finish line for the Olympic sprinter.

What’s an example Definition of Done (DoD)?

Now that we’ve gotten the theory out of the way, let’s talk about the practice.

Let’s take a look at a real-world example of a Scrum Team’s Definition of Done (DoD):

Depending on your needs, you have the final say on how simple or elaborate the DoD is. For example, a Scrum Team working on a note-taking app is likely to have a simpler DoD than one working on an information system for the defense and aerospace sector.

The guiding principles are to start small, keep it simple, and evolve the DoD as needed.