The Definition of Done in Agile (DoD)

We all know the word “done”, but do you know what “done” means to your team?

The definition of done (DoD) is a set of criteria that deems a piece of software “complete” and ready to be shipped. If you don’t have an agreed-upon and shared definition of done, you should create one so that you ensure a high and consistent bar of quality across the organization.

“Definition of Done: a shared understanding of expectations that the Increment must live up to in order to be releasable into production.” – scrum.org

The definition of done is not about getting sign-off or approval from stakeholders or customers. It is a list of valued-added activities to be completed that ensure a high level of quality. The definition of done is an artifact used and managed by the development team.

Why Definition of Done is Important

We meet the definition of done to ensure quality. When an organization doesn’t have a DoD, they suffer from a wide range of output quality. 

In order to describe something as “done”, you must know what “done” means. By defining “done”, you and your team can begin measuring progress in a consistent manner. A good definition of done promotes transparency throughout the team and keeps everyone on the same page to be accountable for a high quality output.

Let’s look at an example of an exchange where the definition of done could have helped.

Product Manager: “I see this feature is marked as ‘done’ but I’m not seeing it in production.”

Developer: “Oh yea, it’s done but we still need to test it and then deploy it.”

Product Manager: “So… it’s not done?”

Developer: “Well, I mean… it’s do – … no, I guess not.”

As you can see, the product manager and developer had two different definitions of done. The product manager’s definition was: code written, tested, and deployed. The developer’s definition was: code written.

The definition of done varies from team to team, but everyone on the team should understand the definition of done.

A small team might have a lightweight and simple DoD. A large, mature team may have an extensive DoD. No matter the size or type of team, DoD should be used to assess when work is completed. 

In other words, “done” = completed. Simple, right? Let’s check out an example.

Example of a Definition of Done for a Feature

1. Code has been deployed
2. Unit tests have 80% code coverage
3. Peer reviewed
4. Tested by a non-developer
5. No sev 1 or sev 2 bugs

The DoD doesn’t need to be an extravagant document. It can be a simple checklist, and it should continue to evolve and change as the team does the same. A good DoD can be used as an actionable and auditable checklist.

Changing the Definition of Done

As teams grow, the DoD changes and strengthens. A good time to address changes to the DoD is during the sprint retrospective but you can change the DoD any time. 

A couple of things to consider when changing the DoD:

1. Don’t weaken the DoD to overcome obstacles.
2. If the change improves the product or process, that’s good.
3. Always be open to improving your DoD.
4. Learn from releases & feature deployments to see where you can add to your DoD.

Enforcing the Definition of Done

In order to enforce the DoD, people need to know about the DoD. Print it out. Bookmark it. Do whatever In order to enforce the DoD, people need to know about the DoD. Print it out. Bookmark it. Do whatever you need to do to share it with the team and get their buy-in and contribution. Embed it into your task management tool, and revisit the DoD during sprint retrospectives to make sure it’s always at the top of mind and always evolving.

Closing Thoughts

When “done” means different things across the team, it creates a team moving in a variety of different directions at different speeds. “Done” is more than simply writing code. Maybe “done” also means training the support team, or having product documentation written. There isn’t a single DoD that will work for each team and product. DoD is a living and breathing thing, unique to your team. Start by writing something down. Share it with your team, and continually improve it.