Why a Definition of Done?

Our team recently moved over to a new way of working, bringing Kanban into our Scrum. As we reviewed our entire working processes, one question came up quite early on in our discussion: why and when should we create our Definition of Done (DoD)?

Some of the team wanted to wait for a sprint or two. The thinking was to go through a cycle, understand how the team will work internally and interact with our systems and stakeholders. Once we had that understanding, they then wanted to start to define some essential standards and aspects to make up a DoD.

Being a Scrum team, we went to the Scrum Guide to find the answer. We quickly concluded we needed something as soon as possible. On the DoD, the Scrum Guide says:

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

As we started to understand the purpose of a DoD, we standard to discuss and answer the following questions.

Who creates the DoD?

Interestingly the guide doesn’t say who must create that DoD; only you need one. From experience, I’ve seen instances where the organisation has a DoD, which all teams must use. In other cases, I’ve seen teams empowered to define their own locally. In general, I have found it to be more mixed. Often the organisation will set its own DoD, with the team adding their requirements as needed to fit their context.

Why do you need a DoD?

Having a DoD means everyone in the team knows what is expected from them and what standard to deliver work. Having a clear DoD fosters transparency and means the team works to fit the broader organisation while maintaining quality.

Therefore, if an increment doesn’t meet the DoD, it’s not done and shouldn’t be presented in a Sprint Review. It would go back into the product backlog for further work or refinement, to be worked on in the next or a future sprint.

The overall purpose of a Scrum team is to deliver the Product Goal. ‘An increment is a concrete stepping stone toward the Product Goal’. Having and following a DoD will give you foundational solid blocks as you deliver each increment and work to achieve your Product Goal.

As a product owner (PO), a DoD is essential for many reasons. First, it will clarify quality and what could be accepted at a Sprint Review by you. Having these common standards will aid the development team, ensuring any code which doesn’t follow the DoD is rejected. This will help ensure the team focuses on delivering quality, keeping technical debt to a minimum. If you rack up technical debt, it will cost you more in the future to maintain your product. Even worse, you may not be aware you’re building technical debt up until problems start to emerge.

When should you create your DoD?

As early as possible, ideally in your first sprint. Remember, the moment a product backlog item meets the DoD, an increment is born. If you’re following Scrum, you need that DoD if you want to have an increment. It will also give everyone a shared understanding along with a meaningful Sprint Review.

What should your DoD include?

That will depend on your team and context. It will also depend on how your PO works and how their product backlog is defined.

If you are a feature team, you will likely focus on what you need to do to get your increment into the next release. Your DoD could then include a range of testing processes, the creation of documentation, integration requirements, compliance requirements and more.

If you use user stories, you might include acceptance criteria, code reviews, testing or even the PO themselves finally accepting the user story.

I’ve also seen teams have a DoD at an epic level, which helps focus on quality and standards at that higher level. Teams here might include standards around end-to-end integration, testing (often regression testing), entry into a production environment and more.

While all of the above are just examples, with teams including much more in their DoDs, one important thing to remember is to inspect and adapt your DoD often. Your DoD in sprint 1 probably shouldn’t look the same as your DoD in sprint 10 or 20. As the team becomes more comfortable working together, and as the product starts to emerge and then evolve, your standards will probably increase. You might choose to make your DoD stricter to raise quality and reduce technical debt.

In true Scrum spirit, nothing is perfect the first time, if ever. We continually inspect and adapt, working as a team to evolve and iteratively improve what we have. The same is true for the DoD. It’s an ongoing conversation for the whole team. It’s a great way of building transparency too.

A DoD and Kanban

We’re increasingly moving over to Lean principles in the way we work. The Kanban Guide doesn’t have any reference to a DoD, in the way the Scrum Guide does. However, in Kanban terms, we see the DoD as an exit policy of our workflow. Moving something to ‘done’ means it exits our system and the cycle time clock stops ticking. There is no incompatibility here between Scrum and Kanban: our DoD is our handoff or exit policy to the ‘done’ column.