Dependencies between teams in Scrum

Last post 08:45 pm May 16, 2019
by Jason Brewster
4 replies
03:45 pm May 15, 2019


I would like to ask you guys for a piece of advice about how to best deal with dependencies between teams that work on the same product.

To my understanding, we should make sure that dependencies are maintained at their minimum level all the time. Backlog refinement should help us to keep product backlog items independant, so that every team can pull those in their respective sprint backlogs, without having to worry if they will have to deal with dependencies during the development phase. (of course, in a ideal world).

Is that correct on a theoretical point of view and consistent with the Scrum Framework?

I am asking you this because one of my fellows scrum master recently passed the PSMI exam, and on a specific question, he had to answer a question about how to efficiently coordonate teams working on a single product. He has hesitated between 2 answers : 1) "reduce dependencies" and 2) "have clear requirements".

What would be the best answer / view to this question and how could it help us operate a better Scrum (at scale) in the real world?



04:13 pm May 15, 2019

Hi Jason,


My opinion and understanding is 2) have clear requirements. Clear requirements in Scrum means well defined product backlog items. If the backup items are properly defined, each Scrum Team will select independent Backlog items into their Sprint Backlog. Therefore there should not be dependencies when requirements are clear. 


Best regards,

Mein Sin

06:23 pm May 15, 2019

My preferred option is "reduce dependencies" but it doesn't always work. 

Your theory seems right to me.  But the real life problem is that you can't always identify all dependencies. It is frequent that while doing work you will uncover something you didn't expect and those can be dependencies.  So, I coach to identify everything you can before during refinement and discuss mitigation plans.  If there is absolutely no way that the team can deal with the dependency on their own, then cross team discussions and necessary coordination must ensue.  But I really encourage my teams to find ways of dealing with a "dependency" on their own.  Is this a dependency in code where the "other team" needs to do the work?  If so, why can't my team do the work and have someone from the other team review it?  That way you aren't waiting on another team to be able to fit the code changes into their sprint before my team can start working.  There are many ways to address dependencies and not all of them require waiting on someone else. This aligns with the "reduce dependencies" philosophy, at least to me. 

Reason I don't agree with the "clear requirements" answer is because the idea behind agile is to be able to work without complete requirements and adapt as deliver increments of value.  Trying to identify clear requirements seems very waterfall-ish to me and reminds me of the days where I had to "test" 100 page requirement documents.  If the answer had been "clear enough to begin work requirements" I might agree.  But as stated, "reduce dependencies" is my answer. 

04:08 am May 16, 2019

a question about how to efficiently coordonate teams working on a single product.

I’m not sure that teams would be co-ordinated, at least not in the sense of co-ordination being something done to them. Rather, co-ordination ought to be facilitated. A significant part of self organization involves teams reducing dependencies of various kinds. If the requirements are clear enough to allow this to be done efficiently, so that the work is understood and may be taken on, then perhaps that is good enough.

09:16 am May 16, 2019

Thank you for your kind and always very instructive answers. Knowledge and experience sharing here is always of great help.

In my point of view, and I agree with you Daniel,  "clear requirements" sounds a lot like good old  Big Design UpFront classical trap and I am not a big fan of this answer. On an other point of vue, there should not exist dependencies as Mein Sin said, and so "reducing dependencies" also sounds like a "not so good" answer.

More importantly, coaching "to identify everything you can before during refinement and discuss mitigation plans" (Daniel) seems to me as a key concern, thanks for the guideline!