Multiple Teams Definition Of Done

Last post 03:09 pm May 22, 2020
by Ahmed Kamal
25 replies
Author
Messages
10:20 pm December 31, 2016

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

Does this mean that each team working off the same PB must adhere to a single DoD, or each team has their own version?

I would have thought that each team has their own version, but that there can be a product-wide DoD and that each team is allowed to add it's own items that suit its own stories.

If I have 2 teams working on a single PB: a UI team and a server-side team. The UI team might have a DoD item like 'All drop-downs menus must be manually tested'. This would not make sense from the perspective of the server-side team.

09:03 am January 1, 2017

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.

11:20 am January 1, 2017

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?

12:28 pm January 1, 2017

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

01:18 pm December 11, 2018

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?

06:54 pm December 11, 2018

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?

08:19 pm December 11, 2018

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.

10:01 pm December 11, 2018

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

11:54 am December 12, 2018

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,

12:02 pm December 19, 2018

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?

07:08 pm December 19, 2018

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

 

09:31 pm December 19, 2018

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.

02:44 pm December 21, 2018

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?

06:52 pm December 21, 2018

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

11:40 pm December 21, 2018

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

07:13 am January 17, 2019

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?

12:48 pm January 18, 2019

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?

03:16 pm February 4, 2019

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?

03:48 pm February 11, 2019

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

05:29 am February 12, 2019

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

06:31 am February 27, 2019
  • 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?

11:17 am March 1, 2019
  • 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.

03:38 pm March 1, 2019

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

05:06 am April 9, 2019

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. 

10:27 am May 30, 2019

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.

02:40 pm May 22, 2020

"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