Overview¶

This guide targets practitioners who already understand basic Scrum (roles, events, artifacts) and want to operate at a program level — coordinating multiple Scrum teams, managing dependencies, and applying Scrum inside complex software development organizations rather than a single team.

Who it's for: Scrum Masters and Agile leads with 6+ months of hands-on experience who are moving into multi-team or program-level responsibility.

Prerequisite knowledge: Scrum roles (Product Owner, Scrum Master, Developers), the five events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and the Sprint itself), and the three artifacts (Product Backlog, Sprint Backlog, Increment).

Core Topics Breakdown¶

1. Scrum at Scale¶

• Scrum of Scrums (SoS): A pattern where one representative from each team meets to surface and resolve cross-team dependencies and impediments.
• Nexus Framework: An officially recognized layer on top of Scrum for 3–9 teams working on one Product Backlog, introducing a Nexus Integration Team responsible for a single "Done" integrated increment.
• LeSS (Large-Scale Scrum) vs. SAFe: LeSS keeps Scrum's minimalism and pushes coordination down to the teams; SAFe adds structured roles (Release Train Engineer, Product Management) and cadences (Program Increment planning) for large enterprises.

2. Program-Level Backlog Management¶

• Maintaining one Product Backlog vs. federated backlogs per team.
• Techniques for slicing epics into cross-team-ready stories (vertical slicing, dependency mapping).
• Managing a Definition of Done that is consistent across teams contributing to the same increment.

3. Advanced Facilitation¶

• Running effective Scrum of Scrums and cross-team retrospectives.
• Conflict resolution between teams with competing priorities.
• Coaching Product Owners on program-level roadmap and release planning (rather than sprint-only planning).

4. Metrics for Program Health¶

• Velocity is a team-local metric — do not sum velocities across teams to measure program throughput.
• Use cycle time, cumulative flow diagrams, and release burn-up charts for program-level visibility.
• Track cross-team dependency resolution time as a leading indicator of program risk.

5. Technical Practices That Enable Scale¶

• Continuous Integration/Continuous Delivery (CI/CD) as a prerequisite for multiple teams integrating into one product.
• Trunk-based development and feature flags to decouple deployment from release.
• Test automation strategy shared across teams to keep the "Done" increment releasable.

Study Tips¶

• Practice mapping a real (or hypothetical) multi-team dependency graph and identify where a Scrum of Scrums would surface a blocker earlier than a standard Daily Scrum.
• Memorize the distinction between scaling frameworks (Nexus, LeSS, SAFe, Scrum@Scale) — exams and interviews frequently test which framework introduces which specific role or artifact.
• Be ready to explain why summing team velocities is a common anti-pattern.

Common Pitfalls¶

• Treating program management as "more process" rather than more coordination discipline — added ceremonies without clear purpose slow teams down.
• Allowing a single dominant team to set the pace for all others without addressing the root dependency.
• Ignoring technical debt at the integration layer, which quietly erodes the ability to scale.

Quick Reference Cheat Sheet¶

Further Practice¶

Draft a one-page charter for a hypothetical 4-team program: define the shared Definition of Done, the SoS cadence, and one metric you'd report weekly to stakeholders.