When a product is being developed by multiple Scrum Teams it is recommended that there be 1 Product Backlog (PB) for that all the Teams draw from to produce their own Sprint Backlogs.

It is probable that 1 Team may be dependent on an output from another Team before they can develop a particular Product Backlog Item (PBI); for example:

• SUPPOSE that part of the product being developed requires a customer to pay for goods/services; we may have a User Story as a PBI something like this:

“As a customer

I need to pay for my goods/services

So that the company will send them to me”

• At some point in the development it is realised that there are so many ways to pay (credit card, debit card, PAYPAL, WorldPay etc) that the User Story could not be completed by 1 Team in 1 Sprint; ie it is an Epic
• It is decided to split the User Story above into 1 User Story for each payment method
• It is decided that the MVP for the next release includes paying by credit card and paying by PayPal
• It is further decided that Team A will develop all the common elements of payment as part of developing the ‘Pay by Credit Card’ functionality and Team B will develop the ‘Pay by PayPal’ functionality, which will use some or all of the common payment elements

Clearly, Team B has a dependency on Team A such that Team B cannot start their part of the payment functionality until Team A has completed their part.

When Scaling Scrum, the aim of Release Planning is to minimise the inter-team dependencies; it is improbable that all inter-team dependencies can be eliminated.

The following are some of the ways that inter-team dependencies could be handled:

• User Story Mapping and Minimal Marketable Features (MMF)

MMF is the group of features that make up the MVP.

The Release Plan may be developed using the following steps:

• Ensure that all candidate features and User Stories/Epics are decomposed to manageable sized User Stories
• Assign User Stories to the MVP
• Assign User Stories to potential Team Sprint Backlogs keeping in mind any dependencies 
• Highlight dependencies

For the payment example above, you may end up with a Release Plan Board and proposed Team Sprint plans that looks something like:

Possible Release and Sprints Plans

You can see that all Release MMF are planned to be finished by the end of Sprint 2 leaving Sprint 3 to cater for any overruns.

• Team Structuring

With the advent of Component-Based Development (CBD), some organised their development teams into Component Teams and Product Teams who ‘glued’ together the necessary components.

If this continued into an Agile environment, then each ‘product’ development team would be dependent on separate component teams and the required coordination would be an onerous task.

In an Agile environment it is recommended to have ‘Feature Teams’; 1 Team should be responsible for the end-to-end development of all of a Feature’s User Stories.  

This does not preclude the reuse of components; part of the organisation’s Design Strategy would require that a separate (possibly non-Agile) Component Management Team (CMT) REVIEWS the output of the Development Teams to see if there is any functionality that could be componentised; the CMT are responsible for componentising the functionality and maintaining a Component Library.

Before writing any code, the Development Team search the Component Library for any components that would be useful.

Component Teams

Feature Teams

• Scrum of Scrum Workshops

Scrum of Scrum meetings are conducted at regular intervals, probably at least once per week, to track dependencies among scrum teams.

• Use Kanban/Scrum Boards to Visualize Dependencies

Dependency threads or tags may be used for visualization of dependencies among features and/or teams.

• Use a Central Dependency Team for Large Enterprise Programs

As part of Agile programme management, “independent” dependency teams may be used to track inter-team dependencies, blockers, external dependencies and ensure they are taken to closure.