License: Creative Commons Attribution-ShareAlike 4.0 International ( CC BY-SA 4.0 ).
© 2026 Ralph Jocham, John Coleman
Disclaimer: No warranties are given. Use at your own risk.
This section is offered under the Attribution-ShareAlike 4.0 International license of Creative Commons.
By using this Scrum Guide Expansion Pack, you agree to the terms of the CC BY-SA 4.0 license.

Multi-Scrum-Team Products

The first rule of scaling is not to scale. There are lots of ways to improve value delivery from existing Scrum Teams. But if you did all that and feel you must still scale, here is some guidance.

If a Scrum Team becomes too large, it should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same Product. Multiple Scrum Teams on the same Product should share a common Product Goal, Product Backlog, Product Owner, baseline Definition of Outcome Done, and baseline Definition of Output Done.

Avoid assuming that more Scrum Teams automatically produce more value. Scale only when the benefits clearly outweigh the overhead. Before scaling, the single Scrum Team setup has to be able to reliably produce an Increment every Sprint, ideally multiple times per Sprint. If scaling becomes necessary, use an approach that is consistent with this document’s guidance. Often, fewer teams result in more outcomes.

In a multi-Scrum-Team context, Scrum Teams may reduce inter-Scrum-Team dependencies by becoming more cross-functional through tighter collaboration around a common goal, knowledge sharing, and intentional interactions. The skills needed vary by domain. In such setups, purposeful, intentional interactions and professionalism (including continuous integration) become even more important.

In a single Scrum Team setup, the Product Owner could be a Product manager, marketing director, technology director, etc. When several Scrum Teams work on a single Product, the ideal is still to have only one Product Owner, who should serve as the Product’s overall leader. To allow the Product Owner to handle multiple Scrum Teams on the same Product, the Product Owner often operates more strategically and delegates problems to solve and opportunities to the Product Developers, including, for example, aspects of customer discovery, Product design, or Product management for parts of the product

The Product Backlog increases transparency. Generally, the fewer Product Backlogs per Product, implicit (like a filter of a Product Backlog) or explicit, means:

• One cohesive direction of travel ((SGEP/Complexity));
• Fewer silos in the Product and greater transparency across the entire Product;
• Clearer visibility into overall progress across the entire Product;
• A better understanding of where value is emerging;
• Easier detection of low-value work from a Product perspective;
• Improved alignment and measurable value outcomes; and,
• A more strategic Product Owner who delegates cross-Product work to the Product Developers.

Fewer Product Backlogs per Product are better for adaptiveness [1]; however, without empowered ownership, a coherent span of control, or regular direct contact with relevant Stakeholders, gaps will appear. Scrum encourages happenstance and multi-learning as people and Scrum Teams collaborate; unplanned discoveries and insights often emerge through these interactions. Such positive emergence rarely occurs when components are isolated behind separate Product Backlogs.

Happenstance in the context of ‘The New New Product Development Game’ [2] describes how sometimes useful ideas or solutions come about by chance, through close collaboration and shared awareness.

Multi-learning means that team members learn in multiple ways and domains simultaneously. They not only deepen their expertise but also acquire skills beyond their primary discipline. They learn as individuals, as a group, and as part of the whole company. This breadth of learning builds flexibility and resilience, enabling Scrum Teams to solve diverse problems more effectively.

Finding the right balance is a dilemma. There are always trade-offs to consider. A reliable heuristic is: The fewer Product Backlogs (implicit or explicit), the better, supported by multi-learning and active knowledge transfer across Scrum Teams, departments, and Products.

Organizational transfer of learning, as described in ‘The New New Product Development Game’ [2], is the process by which knowledge and insights gained in one new Product development area are regularly shared and applied to subsequent areas or other divisions within the organization.

Many organizations are designed for ease of management rather than ease of outcomes. Examine how many Scrum Teams a problem or opportunity touches to deliver value; generally, the fewer involved, the better the adaptiveness.

Free teams from command and control. Favor aligned autonomy, supported by purposeful, intentional interactions within and between self-managing Scrum Teams [3]. Maintain only the minimum required management scaffolding. Balance and nurture Stakeholder expectations and limits. Build agency for change and continual improvement (in a direction of travel) into a cadence. Prioritize designing Scrum Teams for the successful delivery of outcomes rather than for administrative convenience. Where matrix structures exist, consider softening them — they often dilute accountability, hinder autonomy, and can lead to learned helplessness ((SGEP/PsychologicalSafety)).

When in doubt, re-study the New New Product Development Game [2], embrace the good of what’s new in the present, but reject any notions of an industrial complex [4-9] where only the bold few have the agency to act.

References

[1] LeSS (n.d.) ‘Why LeSS? Achieving adaptiveness’. Available at: https://less.works/less/framework/why-less (Accessed: 17 May 2025).

[2] Takeuchi, H. and Nonaka, I. (2014) The new new product development game, Harvard Business Review. At: https://hbr.org/1986/01/the-new-new-product-development-game (Accessed: 21 January 2024).

[3] LeSS.works (n.d.) Self-managing teams. Available at: https://less.works/less/management/self-managing-teams (Accessed: 17 May 2025).

[4] Cynefin.io , V. (2022) Cynefin wiki, Cynefin.io . Cynefin.io . At: https://cynefin.io/ (Accessed: April 4, 2023).

[5] Rancati, A. and Snowden, D. (2021) Managing complexity (and chaos) in a crisis - a field guide for decision makers inspired by the Cynefin framework. Luxembourg, Belgium: Publications Office of the European Union.

[6] Snowden, D. et al. (2022) Cynefin® weaving sense-making into the fabric of our world. 2nd edn. Edited by R. Greenberg and B. Bertsch. Singapore, Singapore: Cognitive Edge - The Cynefin Co.

[7] Snowden, D. (2023) Cynefin St David’s 2023 1 of 2, Cynefin Co. https://thecynefin.co/cynefin-st-davids-2023-1-of-2/ (Accessed: April 20, 2023).

[8] Snowden, D. (2023) Managing for emergence through abduction, The Cynefin Co. At: https://thecynefin.co/managing-for-emergence/ (Accessed: June 24, 2023).

[9] Snowden, D. and Smith, N. (2023) Leadership discussion: Dave and Natalie - the Cynefin co, YouTube. At: https://youtu.be/WcPZ8ybDF0w (Accessed: April 7, 2023).