A feature is either done or not-done. A sprint is either done or not-done. A release is either done or not-done. But what does “done” mean?

“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.

Definition of Done in Agile

Why Definition of Done is Important

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 brings everyone on the same page. Let’s look at an example of an exchange where 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 (DoD for short) varies from team to team, but everyone on the team should understand the definition of done.

A small, young team might have a light-weight DoD. A large, mature team may have an extensive, strong 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.

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 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.

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 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.