Scrum Master Exam: Scaling with Multiple Teams (2026 Guide)

If you've been studying for your PSM I or CSM exam and feel confident about single-team Scrum, congratulations — you've covered the foundation. But here's where many candidates hit a wall: the moment the exam introduces a second team working on the same product, the questions get trickier. Suddenly you're weighing competing interpretations about who owns the backlog, how often integration needs to happen, and what a Scrum Master should do when two teams are stepping on each other's work.

The good news is that the Scrum Guide 2020 is remarkably clear on this topic, even though it doesn't mandate a specific scaling framework. The rules about a single Product Owner, one Product Backlog, and a Done Increment each Sprint apply just as firmly when you have five teams as when you have one. Understanding why those rules exist — not just what they say — is what separates candidates who pass from those who second-guess themselves into the wrong answer.

This guide walks through every major scaling concept you'll encounter on exam day: backlog ownership, integration cadence, Sprint Planning logistics, dependency management, and the Scrum Master's expanded facilitation responsibilities. Expect real-world scenarios, exam mindset tips, and practice questions that mirror what PSM I and CSM assessments actually test.

---

The One Product Rule: Backlogs, Goals, and Owners

The Scrum Guide 2020 is unambiguous: there is one Product Backlog per product, and one Product Owner accountable for it. Full stop. It doesn't matter if you have two Scrum Teams or twenty — this rule doesn't flex. This is one of the most tested concepts in scaled-environment questions, and the traps are subtle.

Consider a scenario where an organization has three teams building a single e-commerce platform. Each team has been given its own "team backlog" managed by a separate Product Owner. From a Scrum perspective, this is a violation. You can have one Product Owner who works with multiple teams, but you cannot split the Product Backlog into independent silos with independent owners. Why? Because the moment you do that, you lose the ability to make coherent prioritization decisions across the whole product. Who decides whether the checkout team's feature outranks the search team's bug fix? Without a single owner and a unified backlog, you get political negotiations instead of empirical prioritization.

What "One Product Owner" Actually Means in Practice

In large-scale environments, the Product Owner often works with stakeholders, Subject Matter Experts, and even delegates some refinement activities. That's fine. What the Product Owner cannot delegate is accountability. They own the Product Goal, they own the ordering of the backlog, and they own the decision about what gets built next. Frameworks like LeSS and SAFe handle this differently at the structural level, but for PSM I and CSM purposes, you're answering from the Scrum Guide — and the Scrum Guide is clear.

Exam mindset tip: When you see a question mentioning multiple Product Owners for a single product, the answer almost always points back to a violation of Scrum. One product, one Product Backlog, one Product Owner.

• The Product Goal is singular and shared across all teams working on the product
• Multiple teams pull from the same ordered backlog — they don't maintain separate ones
• The Product Owner may collaborate with the teams during refinement but retains final say on ordering

---

Integrating the Increment: The Non-Negotiable Exam Rule

This is arguably the highest-stakes concept for scaling questions on the PSM I. The Scrum Guide 2020 states that at the end of each Sprint, the teams must produce an Integrated Increment — a single, usable, potentially releasable increment that combines the work of all teams. Not team A's increment plus team B's increment sitting side by side. One integrated whole.

Think about what "integrated" actually means. If Team Alpha builds a user authentication service and Team Beta builds a dashboard that depends on it, the increment isn't Done until those two pieces work together and have been verified against the Definition of Done. The fact that each team completed its individual Sprint Backlog items is necessary but not sufficient. Integration is the proof.

Why This Rule Exists

The purpose of the integrated increment is transparency. The Sprint Review only makes sense if stakeholders are inspecting something real — something that represents the actual state of the product, not a collection of independently completed components. If integration is deferred to some future "hardening sprint" or "integration sprint," you've introduced a hidden time lag between building and knowing. That lag is exactly the kind of waste and risk that Scrum is designed to eliminate.

In practice, this is where many organizations struggle. Teams build independently all Sprint, then scramble to integrate in the last two days. Exam questions will often describe this scenario and ask whether it's acceptable. The answer is no — not because it's logistically inconvenient, but because it undermines the empirical process.

Exam mindset tip: Any answer choice that suggests integration can happen after the Sprint, or that each team's increment is sufficient on its own, is incorrect from a Scrum perspective.

---

How Multiple Teams Conduct Sprint Planning

When multiple Scrum Teams work on the same product, Sprint Planning becomes a coordination challenge. The Scrum Guide acknowledges this and suggests that Scrum Teams may choose to plan together or coordinate before individual Sprint Planning sessions. Neither approach is mandated — the teams have autonomy in how they plan as long as the outcome aligns.

Here's what a healthy multi-team Sprint Planning cycle often looks like:

1. Pre-Sprint coordination: The Product Owner reviews the ordered Product Backlog with representatives from all teams. This is sometimes called an "overall" or "meta" Sprint Planning touchpoint.
2. Individual Sprint Planning: Each team selects the items it will work on from the Product Backlog, creates its Sprint Goal, and designs its Sprint Backlog.
3. Cross-team dependency check: Teams review each other's plans to surface integration dependencies and make adjustments before the Sprint begins.

Protecting the Sprint Goal in a Multi-Team Context

Each Scrum Team should have its own Sprint Goal — a coherent objective that explains why this particular Sprint has value. In a scaled context, individual Sprint Goals should nest logically under the broader Product Goal. If Team A's Sprint Goal contradicts or undermines Team B's Sprint Goal, that's a signal that Sprint Planning coordination broke down.

The Scrum Master plays a key role here. Their job isn't to manage the cross-team planning calendar — it's to ensure the teams have the space, information, and relationships to self-manage that coordination themselves. If the Scrum Master is becoming the central traffic controller, something has gone wrong.

---

Product Backlog Refinement in a Scaled Environment

Refinement is where the scaled environment gets genuinely complex. With one team, the Product Owner and team can refine together in a manageable session. With four teams and a backlog of 300 items, that model breaks down quickly.

Effective scaled refinement usually involves a tiered approach:

• High-level refinement: The Product Owner refines the top of the backlog with representatives from all teams, focusing on upcoming Sprints and cross-team dependencies.
• Team-level refinement: Each team digs deeper into the items it's likely to work on, breaking them down into actionable Sprint Backlog candidates.
• Cross-team refinement workshops: When a backlog item will require work from multiple teams, a joint session surfaces the full scope and surfaces integration requirements early.

The goal of all of this is the same as single-team refinement: backlog items near the top should be small enough, clear enough, and estimated enough to be pulled into Sprint Planning without major surprises. The Scrum Guide doesn't prescribe refinement techniques, but it does say refinement should consume no more than 10% of the team's capacity. That guideline applies per team, not to some aggregate total.

---

Managing Dependencies Without a Project Manager

Here's a question that trips up a lot of candidates: in a scaled Scrum environment, who manages cross-team dependencies? The instinct for many people is to say "the Scrum Master" or "a project manager." Both answers are wrong in the Scrum sense.

Dependencies are managed by the teams themselves, through coordination, communication, and smart backlog ordering. The Product Owner plays a role by structuring the backlog to minimize cross-team dependencies wherever possible — this is a real skill. The Scrum Master creates the conditions for teams to surface and resolve dependencies on their own.

Practical Dependency Management Tactics

In real-world scaled Scrum, teams use several tactics that are worth knowing for exam scenarios:

• Dependency boards or visual maps that teams maintain and update in real time
• Inter-team agreements about API contracts, shared services, or integration standards established before Sprint work begins
• Representatives attending each other's Scrums when tight integration is required — not to report status upward, but to stay aligned laterally

The underlying principle is self-management. Scrum Teams in a scaled context are still expected to figure out how to work together without a coordinator assigning tasks. When a Scrum Master starts directing cross-team work rather than coaching teams to self-organize it, they've crossed from servant leader into project manager — and that's a red flag on the exam.

---

The Scrum Master's Role in Facilitating Cross-Team Collaboration

The Scrum Master's responsibilities in a multi-team environment expand, but their nature doesn't change. They're still servant leaders. They're still coaching rather than directing. They're still focused on impediment removal and process health. What changes is the scope of that service.

In a scaled context, a Scrum Master might:

• Facilitate a "Scrum of Scrums" — a coordination event where representatives from each team sync on progress, plans, and impediments
• Coach Scrum Masters on other teams, especially if some are newer to the framework
• Work with the organization to remove structural impediments that affect multiple teams — procurement delays, infrastructure bottlenecks, policy conflicts
• Help the Product Owner streamline their engagement model across multiple teams

Scrum Values in a Cross-Team Context

The five Scrum values — Commitment, Courage, Focus, Openness, and Respect — take on new meaning when teams are interdependent. A team that hides its dependency risks from another team is violating Openness. A team that refuses to adjust its approach to accommodate a shared integration standard is undermining Respect. The Scrum Master cultivates these values across team boundaries, not just within their own team.

Exam mindset tip: PSM I questions about the Scrum Master's role in scaling almost always reward answers that reflect servant leadership and team empowerment. Any answer suggesting the Scrum Master should assign work, resolve dependencies directly, or act as a project coordinator is a distractor.

---

Daily Scrum and Sprint Review for Multiple Teams

Daily Scrum

The Daily Scrum remains a team-level event in a scaled context. Each team holds its own 15-minute Daily Scrum. What changes is that teams may choose to send representatives to a brief cross-team coordination touchpoint — sometimes called a "Scrum of Scrums" — to discuss integration issues, dependencies, and blockers that span team boundaries.

The Scrum of Scrums is not prescribed by the Scrum Guide, but it appears in PSM I study materials as a common scaling practice. Know that it's optional, team-driven, and distinct from the Daily Scrum itself. The Daily Scrum is for the Developers to inspect and adapt their own plan. The Scrum of Scrums is a coordination forum, not a status report.

Sprint Review

When multiple teams contribute to a single product, they conduct a Sprint Review together — or at minimum, the output of their work is reviewed as an integrated whole. The Sprint Review is not a team-by-team parade of features. It's an inspection of the single integrated Increment against the Product Goal, with stakeholders providing feedback that informs the next Sprint.

This is an important exam distinction. If a question describes three teams each holding their own separate Sprint Reviews and showing their own increments independently, that's a problem. The value of the Sprint Review is collective inspection — stakeholders seeing how the whole product has moved forward, not just how each team's component fared.

---

Practice Exam Scenarios: Scaling and Integration Questions

Let's look at a few exam-style scenarios with the reasoning you need to get them right.

Scenario 1: Three teams are working on one product. At the end of Sprint 5, each team has completed its Sprint Backlog items, but the teams haven't had time to integrate their work. The Scrum Master suggests adding an "integration sprint" after every third Sprint. Is this acceptable?

Answer reasoning: No. An integration sprint violates the Scrum principle that every Sprint must produce a Done, integrated Increment. Deferring integration reintroduces exactly the kind of risk Scrum is designed to eliminate. The correct approach is to integrate continuously within the Sprint.

Scenario 2: A company has two Scrum Teams building one product. The manager assigns a separate Product Owner to each team to "reduce the workload" on the original Product Owner. What is the likely result?

Answer reasoning: This violates the one-Product-Owner rule. Two separate Product Owners will create conflicting priorities, misaligned Product Goals, and a fragmented product strategy. The solution is to support the Product Owner with better refinement processes or delegate backlog management tasks — not to create two owners.

Scenario 3: Team Omega is blocked because Team Delta hasn't completed a shared component they both need. The Scrum Master steps in and starts assigning tasks to Team Delta to resolve the dependency faster. Is this appropriate?

Answer reasoning: No. This is project management behavior, not servant leadership. The Scrum Master should instead coach both teams to surface this dependency earlier (during Sprint Planning or refinement), facilitate a conversation between them, and escalate as an organizational impediment if the teams can't resolve it on their own.

---

Key Takeaways

• One product = one Product Backlog = one Product Owner, regardless of how many teams are involved
• Every Sprint produces one integrated Increment — integration is not optional or deferrable
• Multiple teams self-manage their coordination — the Scrum Master facilitates, coaches, and removes impediments, but doesn't direct the work
• Sprint Planning in scaled contexts includes cross-team coordination, but each team retains its own Sprint Goal
• Refinement scales through tiered sessions, not by splitting the backlog into separate team-owned silos
• The Daily Scrum is a team-level event; cross-team coordination (like Scrum of Scrums) is separate and optional
• Sprint Reviews inspect the integrated product — not individual team outputs in isolation
• Scrum values apply across team boundaries, not just within a single team

---

The best way to cement everything in this guide is to put yourself in the exam scenarios repeatedly. Reading about the one-Product-Owner rule is one thing; correctly navigating a question where a well-intentioned manager creates two Product Owners to "help" requires recognizing the subtle violation in a realistic context. Practicing with scenario-based Scrum Master questions — especially ones that introduce plausible-sounding but incorrect solutions — is the most effective way to build that recognition before exam day.

---

Frequently Asked Questions

Q: Can a single Scrum Master support multiple teams in a scaled environment?

A: Yes, and it's common in practice. The Scrum Guide doesn't mandate a 1:1 ratio of Scrum Masters to teams. A skilled Scrum Master can serve multiple teams, particularly as those teams become more mature and self-managing. For exam purposes, know that each Scrum Team should have access to Scrum Master accountability — whether that's one dedicated person or a shared one.

Q: Does the Scrum Guide recommend any specific scaling framework like SAFe or LeSS?

A: No. The Scrum Guide 2020 is intentionally framework-agnostic at the scaling level. It states that multiple Scrum Teams working on one product should share a Product Backlog and integrate their work, but it doesn't prescribe how scaling is structured beyond those principles. For PSM I and CSM exams, answer from the Scrum Guide, not from SAFe, LeSS, or Nexus unless the question explicitly asks about those frameworks.

Q: If two teams have conflicting approaches to the Definition of Done, who resolves it?

A: When multiple Scrum Teams work on the same product, they must share a single Definition of Done for the product Increment. The Scrum Guide 2020 is clear that the organization may set a minimum baseline Definition of Done, and individual teams may extend it but not weaken it. If teams have conflicting standards, the Product Owner and Scrum Masters should facilitate alignment — typically during a cross-team retrospective or planning event — until the teams agree on a unified standard that ensures integration is genuinely complete.