Scaling Scrum and Multiple Teams: A Comprehensive Guide for PSM II
Why Scaling Scrum and Multiple Teams Is Important
In today's complex product development landscape, a single Scrum Team is often not sufficient to deliver a large, complex product. Organizations frequently need multiple Scrum Teams working together on the same product. Understanding how to scale Scrum while preserving its core principles is essential for any Professional Scrum Master, as it represents one of the most challenging aspects of agile adoption. Misapplying scaling practices can lead to bureaucracy, loss of agility, and erosion of the very benefits Scrum provides. The PSM II exam tests your deep understanding of how Scrum scales without compromising empiricism, self-management, and the ability to deliver a Done Increment every Sprint.
What Is Scaling Scrum?
Scaling Scrum refers to the practice of having multiple Scrum Teams collaborate on a single product while maintaining adherence to the Scrum framework. The Scrum Guide provides foundational guidance for this scenario, and frameworks like Nexus (developed by Scrum.org) offer additional structure. Key principles include:
• One Product Backlog, One Product Owner: Regardless of how many teams work on a product, there is always exactly one Product Backlog and one Product Owner. This ensures a single source of truth for what needs to be built and a unified vision for the product.
• Integrated Increment: All Scrum Teams working on the same product must produce a single, integrated, Done Increment at the end of every Sprint. This is non-negotiable. The combined work of all teams must be usable and potentially releasable.
• Shared Definition of Done: All teams working on the same product must share a common Definition of Done. If the organization has a standard, all teams must follow it as a minimum. Individual teams may choose to apply a stricter definition, but never a weaker one.
• Self-Managing Teams: Each Scrum Team remains self-managing. Scaling does not mean adding layers of management or removing autonomy from teams. Teams decide how to organize themselves and how to accomplish the work.
How Scaling Scrum Works
Product Backlog Management
The Product Owner manages the single Product Backlog. With multiple teams, effective Product Backlog refinement becomes critical. Teams may refine different parts of the backlog, but they must coordinate to understand dependencies and integration points. The Product Owner may delegate refinement activities but retains accountability for the backlog's content, ordering, and transparency.
Sprint Planning with Multiple Teams
Each Scrum Team conducts its own Sprint Planning. However, when multiple teams work on the same product, they need to coordinate during or around Sprint Planning to minimize dependencies, avoid duplication, and ensure alignment. Teams select items from the shared Product Backlog. The selection process should be collaborative — teams discuss which items each team will take based on skills, capacity, and dependencies.
Integration and Cross-Team Coordination
One of the biggest challenges in scaling is integration. Key practices include:
• Continuous Integration: Teams should integrate their work frequently — ideally continuously — rather than waiting until the end of the Sprint. This reduces integration risk and provides faster feedback.
• Cross-Team Refinement: When backlog items have dependencies across teams, joint refinement sessions help teams understand and plan for those dependencies.
• Cross-Team Communication: Scrum does not prescribe how teams coordinate, but common approaches include Scrum of Scrums, shared channels, integration teams, or communities of practice. The key is that coordination should be driven by the teams themselves, not imposed by management.
The Nexus Framework
Nexus, created by Ken Schwaber and Scrum.org, is the officially endorsed scaling framework for Scrum. It adds minimal process on top of Scrum to address integration and dependency challenges:
• Nexus Integration Team: A team responsible for ensuring that a combined Increment is produced every Sprint. It consists of the Product Owner, a Scrum Master, and one or more members from the Scrum Teams who have integration expertise.
• Nexus Sprint Planning: Representatives from each team come together to discuss and align on Sprint goals, dependencies, and the order of work.
• Nexus Daily Scrum: A daily event where representatives from each team identify integration issues and dependencies.
• Nexus Sprint Review: A single Sprint Review replaces individual team reviews. Stakeholders provide feedback on the integrated Increment.
• Nexus Sprint Retrospective: A combined retrospective to address cross-team issues, followed by individual team retrospectives.
Team Structure and Composition
When scaling, teams should be cross-functional and feature-oriented rather than component-oriented. Feature teams can deliver end-to-end functionality, reducing dependencies and handoffs. Component teams create bottlenecks and integration challenges. Each team should have all the skills needed to turn a Product Backlog item into a Done piece of the Increment.
Common Challenges in Scaling
• Dependencies: The more teams, the more potential dependencies. Reducing dependencies through smart backlog refinement, feature teams, and architectural practices is critical.
• Integration Debt: If teams do not integrate frequently, technical debt accumulates and the risk of a failed Sprint increases dramatically.
• Loss of Empiricism: Adding coordination layers can obscure transparency. Scrum Masters must vigilantly protect empiricism and ensure that inspection and adaptation remain central to the process.
• Diluted Product Ownership: Some organizations try to solve scaling by adding multiple Product Owners or creating hierarchical product ownership. This fragments vision and accountability. There must be one Product Owner per product.
• Imposing Coordination: Management-driven coordination mechanisms reduce team autonomy. Teams should self-organize their coordination methods.
The Scrum Master's Role in Scaling
The Scrum Master plays a crucial role in a scaled environment:
• Coaching teams on maintaining Scrum values and principles at scale
• Facilitating cross-team coordination and removing organizational impediments
• Helping the organization understand that scaling requires simplicity, not complexity
• Ensuring that the Definition of Done is upheld across all teams
• Helping teams identify and reduce dependencies
• Coaching the Product Owner on effective backlog management for multiple teams
• Advocating for organizational changes that support agility at scale (e.g., removing silos, changing funding models, restructuring teams)
Key Principles to Remember
1. Scaling Scrum means applying Scrum at a larger scope — it does not mean changing Scrum.
2. Minimize dependencies between teams through smart team design and architecture.
3. Integration is the hardest part of scaling. Invest heavily in continuous integration practices.
4. The Product Owner role does not split — one Product Owner, one Product Backlog, one product vision.
5. All teams must produce an integrated, Done Increment every Sprint.
6. Teams self-manage their coordination. The Scrum Master facilitates but does not dictate.
7. The Definition of Done must be shared and consistently applied.
8. Feature teams are preferred over component teams.
9. Transparency becomes harder at scale but is even more critical.
10. Add process and structure only when necessary, and keep it minimal.
Exam Tips: Answering Questions on Scaling Scrum and Multiple Teams
1. Always default to the Scrum Guide: The PSM II exam is based on the Scrum Guide. When in doubt, choose the answer that aligns with Scrum's rules. There is always one Product Backlog and one Product Owner per product, regardless of scale.
2. Favor simplicity: When presented with options that add process versus options that simplify, choose simplicity. Scrum values minimizing unnecessary complexity.
3. Protect self-management: Answers that suggest teams should coordinate themselves are generally preferred over answers that impose coordination through management or external roles.
4. Focus on integration: If a question involves multiple teams and an integration problem, the best answer usually involves more frequent integration, shared standards, or cross-team collaboration — not adding roles or checkpoints.
5. One integrated Increment: Remember that all teams produce one combined Increment. There is no concept of separate Increments per team on the same product. If an answer suggests otherwise, it is likely incorrect.
6. Beware of proxy Product Owners: Questions may tempt you with answers that introduce multiple Product Owners, product owner proxies, or business analysts managing parts of the backlog. The correct answer maintains a single, accountable Product Owner.
7. Definition of Done is shared: If teams have different Definitions of Done for the same product, this is a problem, not a feature. The correct answer will advocate for a shared, consistent Definition of Done.
8. Watch for component team traps: Questions may describe component teams and ask for improvements. The answer often involves moving toward feature teams that can deliver end-to-end value.
9. Think about empiricism at scale: If a question describes a loss of transparency or delayed feedback in a multi-team environment, the solution involves restoring transparency, increasing integration frequency, or improving communication — not adding reports or status meetings.
10. Understand the Scrum Master as a servant-leader: In scaling scenarios, the Scrum Master's role is to coach, facilitate, and remove impediments — not to manage coordination, assign work to teams, or act as a project manager across teams.
11. Read carefully for the number of products: A common source of confusion is whether multiple teams are working on one product or multiple products. One product = one Product Owner and one Product Backlog. Multiple products = potentially multiple Product Owners and backlogs.
12. Practice scenario-based thinking: PSM II questions are often situational. When reading a scenario, identify what Scrum principle is being violated, then select the answer that corrects the violation while preserving team autonomy and empiricism.
By internalizing these principles and tips, you will be well-equipped to handle any question about scaling Scrum and working with multiple teams on the PSM II exam.
