The multiple Definitions of Done

#1

After a careful re-read of the Scrum Guide, I noticed a few passages concerning the Definition of “Done” (DoD) which puzzle me and my fellow Scrum Masters. Let me explain our context.

We work on a single SaaS product that was a monolith and is now being refactored into multiple services. We have 14 Scrum Teams working on this product. Each Scrum Team arrived at a DoD with their respective Product Owner. These DoDs are all different although they have some alignment (although the wording is slightly different). Recently the decision was made to drop our old GUI layer and have each service determine the most appropriate GUI library of choice. This triggered me to be concerned about the overall consistency of the Product.

When I re-read the Scrum Guide, I noticed that the DoD might be the point where you have some agreement or alignment on the Product. See for instance this passage in the Scrum Guide:

If there are multiple Scrum Teams working on the system or product release, the development teams of all of the Scrum Teams must mutually define the definition of “Done.”

Transparency requires those aspects [Significant aspects of the process] be defined by a common standard so observers share a common understanding of what is being seen

Those performing the work and those accepting the work product must share a common definition of “Done”

When I pointed this out to my fellow Scrum Masters, their reaction was divided. People pointed out that they were working on different systems, so they should have their own DoD. I digged some deeper and found out that most DoDs are written by and for Developers instead of as a collaboration method between the business and the Scrum Team. On many of our DoDs are assertions that actually don’t concern qualities of the end product, but are more about the process by which it was made. It seems like teams use the DoD more as a way to be transparent about team agreements then a document with the goal to get shared understanding when an increment to the product is done.

If this is all true, then all teams should have a mutual DoD, but how does this relate to this quote from the Scrum Guide?

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.

But we have both mature and new Scrum Teams. This means there will be a shared part of the DoD and a team specific DoD. Do I read this correctly. Are there multiple DoDs: a product/system one and a team one, where the team DoD should always extend the product/system one?

#2

I’m pretty dense, so I appreciate your understanding if I need more clarification on your question(s).

Are you asking if it’s OK for teams to have their own definition? Or what is “appropriate” for a definition of done to include?

If teams are practicing collective code ownership across 1:n products & systems, the teams should absolutely collaborate on a shared understanding of what “done” means. This is especially important when you have new and mature teams, as you say. If team A decides everything must be under a test-first wrapper while team B ignores TDD completely… the codebase will become inconsistent. Let the team members determine how to proceed (e.g., including a definition that includes tests to begin teaching new teams).

If a team will have sole ownership of their work, it’s probably fine for them to write their own definition. I would still encourage the team to be transparent in their definition to other teams, though, simply to promote good practices and knowledge sharing.

Does this help?

#3

I think I am just fishing for how other people approach the DoD and what its primary goal is. I see that it is used as a quality control tool (a checklist of actions that need to be done), while I believe the original intent of the DoD might be to have clear agreements between stakeholders and development what stakeholders can expect of all done increments of the product.

#4

Your belief feels more satisfying and useful to me.