10Planning with several teams

Scrum keeps teams small, typically ten people or fewer, because communication cost grows much faster than headcount: ten people have 45 possible pairs to keep in sync, twenty have 190. A large product therefore needs several small teams, not one large one. Why this makes the "Scrum is only for small projects" belief wrong is discussed in Scrum in Name Only. This section is about how several teams plan together.

Why several teams

• Volume. There is more work than one team can deliver before the date that matters.
• Range of expertise. A BECS needs people who understand donor eligibility, component manufacturing, laboratory testing and logistics. Few teams of ten cover all of it in depth.
• Cognitive load. One team cannot hold the whole of a large domain in mind. Four teams, each owning one area, can.
• Regulatory segregation. Regulations often treat parts of a system differently when they are properly separated. Medical device software can be split into items of different safety classes; financial regulation applies its strictest requirements to the systems that support critical functions. Architecture, regulatory scope and team boundaries can then be aligned.

The real limit on scale is not the number of teams but the dependencies between them. Four teams that rarely need each other scale well. Two teams that block each other every sprint do not.

Dependencies are decided before planning

Most dependencies are created by the way the work is divided, long before any planning session. Three choices make the difference.

• Divide by business area, not by technical layer. A front-end team, a back-end team and a database team depend on one another for every feature. The four BECS teams can each deliver a capability of their own area end to end.
• Make every dependency point one way. Each relationship between two teams should have a clear supplier and a clear consumer. When information must flow back, publish facts, as Blood tests does with positive results.
• Give each piece of data one owning team. A database shared across teams creates hidden dependencies that surface late, usually during integration.

Planning the dependencies that remain

Some dependencies remain, and they are what multi-team planning is for.

• Plan the release together. All teams working on the product plan the release in the same session, against one ordered backlog and one release goal. Scaling frameworks formalise this: Nexus Sprint Planning, joint Sprint Planning in LeSS, PI Planning in SAFe.
• Keep a dependency board. A simple grid of teams against sprints, with each dependency drawn from the sprint in which the supplier delivers to the sprint in which the consumer needs it. Anything pointing backwards in time, or forming a loop, must be resolved before the release starts.
• Schedule suppliers a sprint ahead. The work a team depends on should be finished at least one sprint before it is needed. That margin absorbs normal variation.
• Agree interfaces before implementing them. When teams agree a contract first and test against it, a consumer can build against a stub instead of waiting.
• Share one Definition of Done and integrate every sprint. An increment is done only when it works with everyone else's. The walking skeleton makes this possible from the first release.
• Watch the trend. Count dependencies between teams per sprint. A rising number signals that the boundaries between teams need to change, not that planning needs more effort.

When a team runs late

The chain from donation to inventory gives the release plan a natural order: each area picks up where the previous one leaves off. That order is valuable planning input. It also means that lateness travels downstream. A team that finishes early rarely lets the next one start early, while a team that runs late almost always delays the next.

The walking skeleton changes how far a delay can spread. Without it, the four teams form a pipeline, and every delay ripples through every team after it. Once the skeleton is in place, the interfaces exist. In later releases each team mostly deepens its own area, and depends on the team upstream only when new information has to cross a boundary. The skeleton turns a sequential pipeline into largely parallel work.

When a team does run late, the responses come roughly in this order:

1. Use the margin. That is what scheduling suppliers a sprint ahead is for.
2. Work against the agreed contract. If Blood tests is late with positive results, Inventory can still build quarantine against the agreed "positive result confirmed" event and test it with simulated events.
3. Reorder the downstream backlog. Bring forward work that does not depend on the late item.
4. Help the late team. People from other teams join it for a sprint, where their skills allow.
5. Use the feature buffer. Drop or defer the optional scope tied to the late item.
6. Move the date. The last resort, decided openly with the stakeholders, and early.

Re-planning is joint. At each sprint boundary, all teams review the dependency board together and adjust it. A downstream team should never discover a delay by waiting for something that does not arrive.