Multiple Teams Definition Of Done

Remember that the Definition of Done applies to the product increment, not to backlog items such as User Stories which may be simply associated with a certain level of Done. This is because it is the integrated increment which must be fit for potential release.

All teams involved in creating an integrated increment must observe the DoD for the product, although they may be individually responsible for work that satisfies a particular level of done for that product.

The wider organization can be a stakeholder in the Definition of Done for any or all of its products. Hence teams, when crafting a DoD, should look to the organization in the first instance.

Posted By Ian Mitchell on 01 Jan 2017 09:03 AM
Remember that the Definition of Done applies to the product increment, not to backlog items such as User Stories which may be simply associated with a certain level of Done. This is because it is the integrated increment which must be fit for potential release.

All teams involved in creating an integrated increment must observe the DoD for the product, although they may be individually responsible for work that satisfies a particular level of done for that product.

The wider organization can be a stakeholder in the Definition of Done for any or all of its products. Hence teams, when crafting a DoD, should look to the organization in the first instance.

I get you. You're referring to 2 teams co-building a single increment, and one DoD for that makes sense. But isn't there a use case for 1 product, with 2 scrum teams and each scrum team is working on a seperate increment each. In that case 2 DoD's are possible?

> But isn't there a use case for 1 product, with 2 scrum teams
> and each scrum team is working on a seperate increment each

If they were working on separate increments at the same time then no, that would not be a valid Scrum scenario. An increment must be the sum of all previous increments and it must be fully integrated for potential release. Separate teams may work on their own deliverables for integration into the next increment. Those deliverables may satisfy a level of done that is only relevant to each individually, but the integrated increment must satisfy the DoD.

I do understand that DOD is for Product increment, that is clear

What about the case when teams are continously deploying? there is not integrated increment?

In my case, there are 3 teams working off a single PB,  have a single product owner, work within the same domain but have different DOD's. 

Also they are continously deploying to Production. 

Shouldnt all of them have a common DOD?

What would be the impact on transparency of the quality of an increment, or the progress being made, if there is variance in what is considered "Done"?

How do the Product Owner and stakeholders feel about this variance?

What about the case when teams are continously deploying? there is not integrated increment?

In my case, there are 3 teams working off a single PB,  have a single product owner, work within the same domain but have different DOD's. 

If they are all working on the same product, why is there no need for increments to be integrated? In Scrum, a product’s increments are cumulative.

Going back to the Scrum Guide on this.  In the section where the Definition of Done is described you will find this sentence.

If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of "Done".

Since you have multiple teams working from the same Product Backlog, I will assume that they are working on the same system and thus that statement would apply. 

I think that @Simon and @Ian are both alluding to that statement.  If every team has a different DoD, how would you know that the product is stable at all times or that the increment being delivered is actually done?  I realize that continuous deployment allows for things to be released at any time but even in that situation, the PO should still be involved to make the call on whether it is indeed releasable.  That decision is made up of many factors besides "did it meet the DoD".  

To get a more constructive and on topic review, can you, Sreenivasan, point out exactly how those DoDs are different from one another? It may be than the language is different, but the underlying action is the same,

If i understand well, each team working on the same Product Backlog may have its own definition of "Done", but when the time comes to combine their work into an integrated increment, it's only one definition of "Done" that must be used and respected.

Is it correct?

@Georgios  To reiterate from my previous post.  

Going back to the Scrum Guide on this.  In the section where the Definition of Done is described you will find this sentence.

If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of "Done".

The two teams must have the same definition of done. Since the goal is to have potentially releasable increments at the end of each sprint, if you are not conforming to a single agreed upon DoD how would each team know that their work is potentially releasable?

I will add this statement that comes from the Nexus guide because I feel like it can be applicable in any case were there are multiple teams are working on the same Product Backlog.  It also seems to fit your question better based on your statement of "an integrated increment".  Page 11 of the Nexus Guide.

Individual Scrum Teams may choose to apply a more stringent definition of “Done” within their own teams, but cannot apply less rigorous criteria than agreed for the Increment.

In that context the Increment is the combined increment produced by all of the individual Scrum Teams during the Nexus Sprint.  But I do feel that if one team wants to have more stringent criteria that is agreed upon by the multiple teams, no one should stand in their way.  But they can not relax or override any of the agreed upon DoD.

Georgios, to piggyback on what Dan said:/



If teams working from the same backlog are allowed their own DoD, there is the possibility of additional work required when attempting to create an integrated increment.



Therefore, the use of a baseline DoD across all teams working from the same backlog (that guarantees a potentially-releasable increment) is required in order to avoid the above scenario.

Ian mentioned:

Remember that the Definition of Done applies to the product increment, not to backlog items such as User Stories

Scrum Guide in the beginning talks about both:

When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means.

But moving further it continue to focus more on the increment:

This is the definition of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment.

Shouldn't we consider the definition of done for both - PBI and increment? Is there any harm in doing that?

As long as everyone on the team is clear about what “Done” means, then there is no harm.

If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of "Done" - Scrum Guide

Can there be multiple DoD when multiple teams are working on the same project?

In one place (page #18) The SCRUM Guide says : 

Definition of “Done”:

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means.

Although this may vary significantly per Scrum Team,

members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

In another place (page #18), it says: If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done.”

Which one is correct?

Which one is correct?

Both are. 

Can you see the differences and understand the rationale behind the statements?

Can there be multiple DoD when multiple teams are working on the same project?

If they're working on the same product, then it's highly recommended to have a single DoD that applies to the integrated work (increment), but individual teams can have their own DoDs which cannot have reduced standards compared to the Increment level DoD.

Let me give you an example (probably not the best one, but still very good, I'd argue): think of US. US is a federal country. There is a federal Constitution (US Constitution, famous worldwide), but the states (Illinois, California, Texas, New York, Iowa, etc) also have State Constitutions (Illinois Constitution- and guess what, they can't conflict, in terms of provisions, with the US Constitution.

The analogy would be:

• Increment DoD = US Constitution
• Individual team DoDs = Illinois Constitution, California Constitution, Texas Constitution, New York Constitution, Iowa Constitution

Makes sense now?

Thank you so much, Eugene. 

So, the correct answer for the question: Can there be multiple DoD when multiple teams are working on the same project?

Yes/No?

I think should be YES. What you say?

If multiple teams are working on the same product, they may have multiple definitions of done in place, as long as they all agree to follow the incremental DoD, and any other individual team's DoD are in full agreement with the increment DoD, while, eg, having stricter quality provisions

Thank you, Eugene. I hope, I got it :) .

• ScrumTeam-A and ScrumTeam-B work on the same product.
• The DoD of their organization contains Item-X, Item-Y and Item-Z.
• So that, ScrumTeam-A's DoD contains Item-X, Item-Y and Item-Z.
• However, ScrumTeam-B cares about technical debt and refactoring is relatively more important for them. So, ScrumTeam-B's DoD contains Item-X, Item-Y, Item-Z, plus A-Refactoring-Item.

In thiscase, I see no harm that those two different teams working on same product have different DoDs.

"Definiton of Done can be different for different teams working on the same product" is a True statement.

What do you think?

• ScrumTeam-A and ScrumTeam-B work on the same product.
• The DoD of their organization contains Item-X, Item-Y and Item-Z.
• So that, ScrumTeam-A's DoD contains Item-X, Item-Y and Item-Z.
• However, ScrumTeam-B cares about technical debt and refactoring is relatively more important for them. So, ScrumTeam-B's DoD contains Item-X, Item-Y, Item-Z, plus A-Refactoring-Item.

I'm not convinced that Team B's is different than Team A's. That "A-Refactoring-item" looks to me like an ad :)

Isn't refactoring a common best practice that the Scrum team should be aware of, and aim to perform, where and when possible, as part of the usual activities? Refactoring should be (or become) part of the team's DNA. Putting it on a DoD may indeed create transparency and raise awareness, but you don't necessarily need refactoring to create a done, useable, potentially releasable increment.

At least this is how I see it.

@Celal and @Eugene are both correct.  Yes, two teams working on the same product backlog can have different DoD as long as they are both inclusive of the same criteria and only extra criteria exists.  The Product DoD is to be used as a minimum set of criteria that must be satisfied in order for an increment to be "Done". The example that @Celal gave is a very good one.  The two are different but both contain the same criteria at a minimum. This helps everyone, inside and outside of the team, to understand a minimum set of requirements for an increment to be "Done". 

This is still confusing, and the confusion arises by mixing up DoD for the Increment vs what each team member (for single team) or team (for Scale) considers done from their perspective, which is in itself anti-scrum. All references in the Guides (Scrum and Nexus) use Definition of "Done" which appears to be specifically targeting the Increment which can have only one DoD, regardless what each team-member or sub team considers done from their contribution. Many of the question banks have this question, (mPlaza gives it as True, and Lapshin as false)  ambiguous questions like this should not make it into the exam unless its clarified. 

The phrase "must mutually define the definition of "Done"." clearly and firmly stated that DoD must be one, must be mutually defined to avoid any ambiguity. One Mutually Defined DoD is ensure deliverable Increment as well, which is core purpose of following Scrum.

"Any one product or system should have a definition of “Done” that is a standard for any work done on it." - Scrum Guide.

https://www.scrumguides.org/scrum-guide.html#artifact-transparency-done

Hi,

I followed this topic closely and understood that if teams were working on the same product, then it was highly recommended to have a single DoD that applied to the integrated work (increment). Individual teams still could have their own DoDs which could not have reduced standards compared to the Increment level DoD.

Scrum Teams Definition of “Done” = Integrated Increment level Definition of “Done” ( common across all the teams) + Scrum Team Specific Definition of “Done”.

The New Scrum Guide states "If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done."

I am a bit confused now. Can the Scrum teams have different Definition of Done's if they choose to apply a more stringent definition of “Done” within their own teams? Understood that they cannot apply less rigorous criteria than agreed for the Increment.

I do not see that anything significant has changed about the Definition of Done.  The new revision just helps to focus the scope of the Definition of Done to the Increment because confusion has bred around it's scope.  Many wanted to have a Definition of Done for tasks, stories, increments, releases, and more.  This just lead to confusion because you had to ask which definition of done was being used. The Definition of Done is the commitment for what Developers mean when they say an increment is done.  The word "done" can be used for a lot of purposes (i.e. I'm done with my task, That story is done, I'm done with my research, I'm done with my meeting with my manager, I'm done with the conference room) but the Definition of Done is only used for one thing. 

Can multiple teams working from the same Product Backlog have different definitions of what done means?  Sure, but they all have to agree on a single Definition of Done is so that everyone in the organization will understand what "done" means for the latest increment of the Product that they are building.

Thank you so much for clarifying Daniel. This explanation will go a long way for all of us!

Each team can have their own DoD that is derived from the DoD of the product they are working on for as long as their DoD is more stringent than the overall product's DoD. 

Scrum Guide says

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

however Scrum training manual says:

"When multiple Scrum Teams are working on a single project, it might not be possible to use the same definition of “Done” for all teams, because they might be working on items of different natures. In such a case, each Scrum Team will define its own definition of “Done” and delivers its items based on that definition. However, the integration of those definitions of “Done” should be capable of creating a potentially releasable Increment in the project level."

Which one is correct?

The co-creators of Scrum stand behind the Scrum Guide. The training manual wording is confusing to me because it mentions 'projects'. Yes, you can still use Scrum on projects if you like, and think of every Sprint as a project, where at the end of a Sprint at least one valuable Increment has been delivered. However the Definition of Done provides transparency for the product Increment, and if multiple teams are working on the same Product (via projects), then they share a Definition of Done.

In summary Done includes integration when more than one Scrum Team is working on the same product, hence if the three projects all result in changes to the same product, they would share a Definition of Done.

Where did you get the "training manual" and what is it training?  The use of the word project is troublesome. 



Scrum speaks in the context of a product not projects. The Scrum Guide states

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



Your manual seems to say that an increment is a combined result of multiple teams. In some of the scaled versions of agile processes that might be true but that would not be Scrum.