How Can We Coordinate Multiple Teams? (Shared Backlogs)

Much of the time, the functionality required to deliver business value is substantial enough to require being worked on by multiple teams. A good way to coordinate those teams is usually to make them part of a larger cross-functional team).  However, organizing this way is not always possible or effective. Sometimes people try Scrum-of-Scrums, but that often doesn’t work either. And SAFe has its own way of coordinating teams, but can be too heavy for the smaller mid-scale organizations (50-100, while mid-scale can go up to 300).

A good alternative at mid-scale is to start with a program-level backlog and apportion the work into backlogs for the teams in such a way that the work done during sprints performed in parallel by all the teams will combine to deliver a larger piece of functionality that can be demonstrated to the customer.

Main Points

  • What to do when cross-functionality alone is not enough to deliver business value
  • How to deliver business value more quickly across multiple teams, using backlog coordination

The Power of Backlog Coordination

Scrum suggests having self-organizing cross-functional teams. In the prior chapter we saw how violating this rule of cross-functional teams can cause problems. But sometimes large applications require specialization at the component level, making true cross-functionality impossible. The same difficulties we saw earlier show up, but in a different manner and may not always be recognized. One method that has been attempted to coordinate different component teams in Scrum, is called Scrum-of-Scrums.

Unfortunately, there is not much experience in this approach working well. And when it does, it is still on a small scale.

This paper proposes another method – that of coordinating the backlogs of the teams involved – to lower the amount of coordination needed while achieving quicker feedback loops. This also helps create the sense of a larger team, one which all members of the smaller teams involved can relate to.

Patterns of Challenge

Teams complete sprints relatively well, but are not able to deliver in a timely manner. This occurs then each team is working on some component of a feature well, but does not coordinate well with the other teams that are needed to complete the business capability that this component is a part of.

When Product Size Prevents True Cross-functional Teams

There are often valid reasons to have teams building components for other teams. For example, there may be a component team that builds modules for different applications of a company. Unfortunately, a side effect of this is that true cross-functionality is lost. When this situation occurs, what is the best method to avoid the delays that occur when cross-functional teams are not present?

Building by Sprint, Integrating at Feature Level

Let’s look at the situation where we have a hundred or so developers organized around two or more product lines which we’ll call Product Line A and Product Line B. Each of these applications has their own component team that develops shared methods. There is also a component team that works across applications.

In many ways this is just a larger scale example of the earlier problem discussed in The Value of Cross-Functional Teams. One solution would be to create cross-functional teams that had folks from each application, the component team(s) for the application and the component team(s) that ran across applications (in reality there was more than one team for each of the type of components being built). If this is possible, I would recommend it. But what if it weren’t? How would you do the work? This is a situation I’ve seen many times. Unfortunately, there is a symptom that often occurs with this type of team structure. This is that teams can often write and test code within their sprints, but that actually getting something out the door takes much longer. I remember working with a client that had very good expertise with Scrum telling me that all of their teams finished writing and testing their stories each sprint but that actually delivering something took a couple of months. These two statements did not really jibe with each other so we did a little value stream mapping to see what was happening.

The teams involved represented a cross-section of teams – all together working to develop a set of functionality.

Let’s look at a representation of the value stream of the work these teams do.


The teams now take these backlogs and work at their own discretion. This typically means they are not well coordinated.

After completing their first sprint, the teams select work for the second sprint. Notice that while the work from the first work may be completed, because each team did not coordinate with the other teams in which work they took off the product backlog, they were unable to do any significant integration after the first sprint.

Teams finally get to the point where all of the work done for the feature is completed and they can now integrate their work.

Of course, now we have to integrate the combined pieces. The challenge is that it’s been several weeks that we’ve been working on these different parts of the system and integration will take longer than if had been doing it on a continual basis. It’s also not possible to show functionality until this point so our feedback loop is much longer than the length of the sprint.

Integrating Across the Feature Level

The question arises how to solve this challenge. Lean flow tells us not only do we want to have the time from start (“conception”) to completion (“consumption”) as soon as possible, but to have as few delays as possible along the way. This means quick feedback loops along the entire value stream. Clearly it is better to get feedback to show the customer as soon as possible. Scrum as well implies this. If we are supposed to deliver working software at the end of every sprint, even though it’s not possible for each team to do so, it is clear that the team of teams should be delivering working software every sprint.

Therefore, instead of giving the teams their backlogs independently, they should be split up in a way that the work done by them all in each sprint aligned between them will deliver a piece of functionality that can be demonstrated to the customer.

The Macro Team

In making decisions on how to develop software, Lean’s mantra of “optimizing the whole” provides essential insights.

In this case, instead of focusing on how each team individually works, we must consider the macro-team, that is, the larger team actually building the software. How will it best develop software with the shortest feedback loops possible?

The improved feedback cycles that this method provides enables demonstration of the software at a much quicker pace and lowers the amount of integration work required. This also allows all of the teams a greater vision of what they are building.

“All You are Doing Is Creating a Bigger Team”

At the first client at which I suggested this, one person said that all I was doing was creating a bigger team. I think he’s right. That is, instead of three teams that have to work together, we now have one larger team working together. The insights provided to do this, however, come from understanding Lean flow. It was clear that building software that wasn’t able to be demonstrated was the problem. The missing piece was focusing on how to shorten the feedback loops and the optimization across the teams involved. This underscores my observations for years that Scrum, under the context of Lean flow, is much more effective than Scrum alone.


When functionality that carries business value is too big to be developed by a single team, and cross-functionality alone is not enough to coordinate a team-of-teams, try aligning the teams by using coordinated sprints whose outputs integrate at the end to produce overall business function.