‘Big Room Planning’, or PI Planning, is one of the core events of the SAFe Scaled Agile Framework. It’s an event where all the teams on an Agile Release Train (ART), plus stakeholders, get together for 2 days to plan and align on goals for the next production time-box, or Program Increment – typically 4 to 6 sprints.
SAFe Big Room Planning is a multiple team/multiple sprint planning exercise. It is the SAFe solution for large programs where multiple delivery teams are needed to construct and deliver large systems, typical of most commercial software systems. These systems are required to support large business operations like banking, insurance, or healthcare. These organizations are often subject to regulatory constraints, and (understandably) likely place more value on planning and predictability over risk-taking and innovation. These companies are likely to have more stable product roadmaps than technology companies, and hence multi-sprint planning is not as potentially wasteful. The planning challenge is at least two-dimensional: the production capacity of multiple teams is needed to make progress within meaningful market windows, and, business leaders want visibility of what is being delivered beyond the next sprint. The SAFe product delivery framework addresses both problems.
During the covid pandemic the world self-quarantined and practiced social-distancing. The idea of getting 200 people together in large conference rooms for 2 days and happily sharing the same air was inconceivable. Big Room Planning was dead. Organizations scrambled to find alternative ways of accomplishing the goals of a planning event without being physically together. The use of video conferencing applications like MS Teams and Zoom become ubiquitous. A plethora of collaboration and content-sharing applications (Mural, Miro) emerged to replace flip-charts and soon become part of everyday corporate life.
Many organizations put themselves through excruciating contortions to continue PI Planning as prescribed in the SAFe framework, for example running the event at multiple locations and multiple time zones simultaneously by maintaining constant audio and video communication between the sites. Question: Why is this even necessary?
Having all teams and stakeholders assembled in one place at the same time does have major benefits including:
- Fast decision-making – answers to planning questions are readily available.
- Resolution of cross-team dependencies.
- Relationship-building.
Are there other solutions for these challenges?
- Dependency management – minimize dependencies by designing true cross-functional feature delivery teams
- Fast decision-making – highly autonomous cross-functional teams are also key here, but, there is also no reason why planning must be completed in 2 days. It can take any reasonable length of time so long as it is completed before the next PI cycle begins, and the production cadence is not interrupted.
- Virtual Happy Hours (for those who enjoy that kind of thing).
Many organizations have tried to adopt a scaling framework but have severely handicapped themselves in the process. Badly designed, non cross-functional teams, weighed down with dependencies, and with features shared between multiple teams. The resulting program boards (ART Planning Boards) look like the work of a mischievous kitten let loose with a big ball of yarn. One does not have to think deeply to see the accumulation of WIP and delay.
Meanwhile, at the other end of the scaling ideas spectrum we have other frameworks (LeSS, Nexus, Scrum@Scale) whose stated philosophy is to keep things as simple as possible, and resist against layering additional governance mechanisms – additional roles, events and artifacts, on scrum teams, but instead encourage solving common scaling challenges by reducing cross-team dependencies, and refactoring monolithic architectures. None of these frameworks have any specific mechanisms for multi-sprint planning.
At the highest level of abstraction, we have two sets of processes at work: a set of feature intake processes that supply ready work to a product backlog, and then on the downstream side of the backlog, a set of delivery mechanisms that consume backlog items and transform them into working product increments.
There are only a few basic patterns (with variations) on the delivery side.
Pattern 1: Multiple Teams, Multiple Sprints (SAFe Model)
The job of the business team is to ensure that the product backlog is populated with well-defined work (features), ranked by business value, and that there is sufficient backlog depth to supply the ART with at least one PI’s worth of ready work. The delivery teams for their part will break down work from the backlog into story-sized pieces (via story mapping), estimate each story, and, using knowledge of their velocities, derive an estimate of the approximate delivery date (to the nearest sprint) for each feature. Teams will use the mechanics prescribed by the SAFe Program Layer to get here. The resulting feature delivery timeline from each team is consolidated into the SAFe Program Board artifact, which is a representation of the feature delivery plans for the entire ART for the PI. A PI planning event has some other aspects, but essentially the output is an estimate of the scope and timeline for what can be delivered within the next multi-sprint time-box.
Pattern 2: Multiple Teams, Regular Scrum
The LeSS, Nexus and Scrum@Scale patterns are based on real Scrum. In each case we have a single Product Backlog and a single Product Owner for each product. Both LeSS and Nexus insert one additional step where work for the next sprint is selected from the Product Backlog for each team prior to regular sprint planning. In reality most teams (especially teams in a value stream-aligned organization) already know which subset of the backlog they will work from, so this step is likely low overhead. All teams march to the same cadence with all sprints starting and finishing on the same day. There are no additional roles like Chief Product Owners, or RTE’s. The scaling models in these frameworks try to stay as close as possible to pure scrum with minimal additional governance. LeSS, for example, is optimized for adaptiveness, and unlike SAFe, has no mechanisms for multi-sprint planning. It’s proponents would argue it is pointless building 6-sprint delivery plans as product backlogs are in a continuous state of refinement and re-prioritization (as suggested by the diagram). Multi-sprint delivery plans with additional roles to support the required governance overhead seems uncomfortably un-agile.
But business leadership wants, not unreasonably, a view beyond the next sprint, say for the next quarter – is SAFe the only effective answer? Most organizations will use some form of product roadmap as a way of laying out product goals and priorities over time. Product owners may use roadmaps to outline future product capabilities and as an aspirational timeline for when new features will be released. In an agile organization roadmaps are not commitments but represent a set of prioritized goals for the evolution of a product over time, and like product backlogs, subject to continuous refinement and re-prioritization. At scale, multiple agile teams will share a single product roadmap. Feature delivery velocity can be measured and a determination made of whether current production capacity (number of teams) is sufficient to meet business objectives represented in the product backlog and product roadmap. Over time, teams can become good at forecasting feature delivery without resorting to story-level estimation for multiple sprints.
A Different Model: Continuous Alignment Through Flow
Big Room Planning (and PI Planning in general – regardless of format) is often treated as the mechanism that creates alignment at scale. But in reality, it is compensating for something the system cannot do on its own. It is compensating for the inability to maintain alignment continuously.
When a delivery system is carrying too much work in progress, coordination becomes unavoidable. Dependencies multiply. Priorities shift midstream. Integration becomes fragile. Under those conditions, bringing large groups of people together to reconcile plans feels necessary.
But the planning event is not solving the problem. It is organizing the overload. A different approach is possible. Instead of aligning work periodically through large-scale planning events, alignment can be built directly into the system itself. This is what a flow-based delivery model enables.
In a flow-based system:
- Work is not batch-planned in large increments
- It is pulled continuously from an economically ordered backlog
- Entry into the system is controlled through WIP limits
- Progress is monitored through flow signals such as aging and cycle time
- Decisions are triggered by real-time system behavior, not calendar events
Alignment is no longer something that has to be manufactured every quarter. It becomes an emergent property of a well-regulated system.
What This Looks Like in Practice
Instead of:
- committing to a large batch of work every 8–12 weeks
- coordinating dependencies upfront
- managing delivery against a fixed plan
Teams operate in a continuous flow model:
- The backlog is always prioritized and ready
- Teams pull the next most valuable work when capacity is available
- Work is broken into small, flow-friendly units
- Delivery is governed by WIP, aging, and throughput
- Coordination happens as needed, not as a scheduled event
The question shifts from:
“Did we deliver what we planned?”
to:
“Is work flowing through the system predictably and at the right pace?”
The Role of Leadership
In this model, leadership shifts as well.
Instead of focusing on:
- planning accuracy
- commitment tracking
- alignment ceremonies
Leaders focus on:
- controlling demand
- limiting work in progress
- ensuring backlog quality
- removing systemic constraints
- responding to flow signals
Governance becomes:
a continuous control function, not a periodic planning ritual
Big Room Planning Was Never the End State
Big Room Planning can be useful. It can expose dependencies. It can reveal complexity. It can bring hidden problems into the open. But it is not the destination.
It is a transitional mechanism for systems that have not yet learned how to regulate flow.
As systems mature:
- work becomes smaller
- dependencies reduce
- backlog quality improves
- flow stabilizes
…and the need for large-scale planning events diminishes.
Eventually, it disappears altogether.
The Real Shift
The real shift is not from one planning method to another.
It is from:
batch coordination
to:
continuous flow control
When work is controlled at the point of entry, and regulated as it moves through the system, alignment no longer needs to be forced.
It is built in.
Final Thought
Big Room Planning is not dead because it failed. It is becoming unnecessary.
Not because organizations need less alignment — but because they are learning how to achieve alignment in a simpler, more direct way:
by controlling the flow of work, rather than repeatedly planning around its instability.
For more flow-based PI Planning, see this article: Beyond PI Planning.
For more on the SAFe model for PI Planning, get the book from Amazon: SAFe PI Planning: A Step-By-Step Guide.
Or, get the eBook:
eBook Contents:
- Chapter 1. Introduction to the Scaled Agile Framework. This provides an overview of the SAFe framework.
- Chapter 2. Organizing for scaled delivery. Describes the organizational prerequisites for successful SAFe adoption.
- Chapter 3. Constructing an ART Backlog. The ART Backlog is the starting point for PI Planning. This chapter describes how to create a backlog that is aligned with product vision and strategy and has product features sufficiently well-refined to support PI Planning.
- Chapter 4. PI Planning Step-By-Step, takes you through each of the basic steps of planning a PI.
- Chapter 5. PI Execution Practices explains the essential roles, practices, and artifacts necessary for successful execution and delivery throughout a PI.
