07One product, many teams
Unity at product level, autonomy at context level: goals, backlogs, ownership and the integrated Increment.
The aim of a multi-team organisation can be stated simply: a set of sub-projects as independent as possible, all contributing to the same product. Bounded contexts provide the independence. Scrum's product-level elements, the Product Goal, the Product Backlog and the integrated Increment, provide the unity. The art lies in keeping both.
The tension
The Scrum Guide is firm: one product, one Product Goal, one Product Backlog, one Product Owner. DDD encourages teams to own their part of the domain with as much autonomy as possible. Pushed too far in one direction, the product becomes a federation of components with no shared purpose. Pushed too far in the other, the context teams become feature factories pulling tickets from a common queue, and the boundaries erode.
The answer is not to choose but to assign each decision to the right level.
| Element | At product level | At bounded-context level |
|---|---|---|
| Goal | One Product Goal, expressed in business outcomes | Sprint Goals stating each context's contribution to it |
| Backlog | One Product Backlog, ordered by value across the product | Areas of the backlog aligned with contexts, refined with the owning team |
| Ownership | One Product Owner accountable for value | Area owners or delegates who know the subdomain and its experts |
| Language | A small shared vocabulary at the boundaries | A rich ubiquitous language inside each context |
| Quality | One Definition of Done for the integrated Increment | Additional criteria where a context needs them, such as safety evidence |
| Architecture | The context map and its relationships | The model and design inside the context |
Table 4 · Dividing decisions between the product and its bounded contexts.
Backlog areas aligned with contexts
Large-Scale Scrum (LeSS) offers a well-tested pattern for very large products: the Product Backlog is divided into requirement areas, each with an Area Product Owner and a group of teams, while the overall Product Owner keeps the product-wide ordering. When requirement areas follow bounded contexts, two benefits follow. Backlog items arrive already phrased in the context's language, and most of them can be done by the owning team without help.
Items that genuinely span several contexts still exist. They are a signal worth reading. A few are normal. Many, sprint after sprint, mean either that the context boundaries are wrong or that the items are sliced by technical step rather than by business capability.
When a context becomes a product
Some bounded contexts serve several products or many internal consumers. A patient identity service, a terminology server or a payment platform is used far beyond any single product. In those cases it is more honest to treat the context as a product of its own, with its own Product Owner and backlog, and its consumers as its customers. Team Topologies calls this a platform team. The open host service and published language of section 06 then become its product interface.
An integrated increment every sprint
Scrum requires a usable, integrated Increment at least every sprint. With well-drawn contexts, integration risk concentrates at a small number of explicit boundaries, where it can be tested continuously. Contract tests between producers and consumers, run in every build, catch most integration defects long before a Sprint Review. In Nexus terms, the Nexus Integration Team then spends its time on the context map and its boundaries, rather than on untangling a shared code base.
Section takeaways
- Unity belongs at product level (goal, backlog ordering, Definition of Done); autonomy belongs at context level (model, language, design).
- Aligning backlog areas with bounded contexts makes most items doable by one team. Persistent cross-context items signal wrong boundaries or wrong slicing.
- Contexts used by many consumers are better treated as products, and contract tests at the boundaries make an integrated Increment every sprint realistic.