Big-room planning, explained: what actually happens in the two days everyone dreads

An honest first-timer's guide to PI planning: the two-day arc, the confidence vote, and how to walk in ready.

A mentee sent me a screenshot last month, three panicked emojis attached. It was a calendar invite: "PI Planning, Day 1 of 2, 8:00 to 5:00." Under it sat a second invite for day two. Under that, her message: "Two full days? What happens in a planning meeting for two days?"

She'd been a Scrum Master for four months. Her company had just rolled out SAFe, and the only briefing anyone gave her was "attendance is mandatory" and "bring your backlog." She was bracing for a standup that lasts sixteen hours.

I told her what I'll tell you. Big-room planning is either the most useful two days your program spends all quarter, or the most expensive theater you'll ever sit through. Which one you get depends partly on leadership, and partly on things you can do from where you're standing. Here's the walkthrough I gave her: the arc, the dread, and how to be useful at your first one.

Every team, one room, on purpose

Big-room planning is what it sounds like. Every team building the same product or program goes into one room, physical or virtual, for two days, and turns a prioritized backlog into a plan for the next eight to twelve weeks. SAFe calls that block a Program Increment, hence PI planning. Other shops just say big room planning or quarterly planning. Same animal.

Here's the part the invite never explains. The plan document isn't the point; ten teams could write plans from their own desks. The point is that your plan and my plan touch. Your feature needs an API from my team. My work waits on a platform upgrade owned by a third team. Planned separately, those collisions surface in week six as a blocked sprint and an angry escalation. Planned in one room, they surface on day one, as a piece of string taped between two boards.

That string is the entire justification for the cost. Dependencies become visible while they're still cheap to fix.

Day one: context in the morning, string everywhere by four

The morning belongs to context. Someone senior lays out where the business is: what customers are doing, what changed, what can't slip this cycle. Product management walks the top features in priority order. An architect flags what's changing underneath. Done well, by lunch everyone in the room can answer one question: what matters most, and why.

Then the room flips. Teams scatter to their boards and draft plans sprint by sprint: which features, which stories, what their honest capacity allows. This is the loud part. Product Owners negotiating scope. Someone discovering that the "small" feature is not small.

And then the strings appear. Every time a team finds work they need from another team, someone walks over, has the conversation that was never going to happen over email, and strings a dependency between the two boards. By mid afternoon the program board looks like a loom. Every string is a week-six surprise getting caught in daylight.

Day one closes with a draft plan review. Each team gets a few minutes: here's what we're taking, here's what we need from others, here's what scares us. You'll hear "we'll take that offline" a dozen times in that hour. Learn the translation early. Sometimes it means "this is a two-person detail and the room doesn't need it." Fair. But when it lands on a scope conflict, or a dependency nobody wants, it means "we'd rather not have this argument in public." Notice which one you're hearing. Tomorrow's problems get built from the offline pile.

Overnight, the plan gets a haircut

After the room empties, leadership stays. They hold the drafts up against what they walked in wanting, and the two never match. Too much scope. One team overloaded. Two features quietly fighting over the same three people. So they make calls: trim scope, reorder priorities, sometimes pull a feature entirely.

Day two opens with those adjustments read back to the room, and this is the moment that tells you what kind of organization you work for. The best day two I've sat in opened with a director saying "we heard you, feature four is out." If leadership genuinely moved scope overnight, the event is working. If they came back with "keep everything, just try harder," you're not planning anymore. You're decorating a fiction.

Day two: the re-plan, the vote, and risks with names on them

Teams re-plan against the new shape. It goes faster than day one: boards update, strings get re-strung, objectives get finalized. Then come two closing rituals people love to mock. Done honestly, they're the least theatrical things in the room.

The confidence vote. Every team gets the same question: how confident are you that this plan will hold? Everyone votes at once, one finger to five. Mostly threes and up, the plan stands. Ones and twos, the voters say why, and the plan changes until the hands do. It's one of the few moments in corporate life where a junior engineer can stop an executive's plan by being right.

The risks get ROAMed. Every risk raised across the two days gets sorted, in public, into four buckets: Resolved (no longer a risk), Owned (a named person takes it), Accepted (we're living with it, and we said so out loud), or Mitigated (we have a plan to shrink it). The acronym matters less than the move. A risk with a person's name on it behaves completely differently from a risk on a slide.

Why the dread is earned

I won't pretend the eye-rolls come from nowhere. The dread has three honest sources.

It's expensive. A hundred-person program in one room for two days is close to a person-year of working time, before anyone books a flight. If the output gets abandoned by week three, all that money bought was a very elaborate team lunch.

The theater risk is real. The framework's picture is decisions made live: scope negotiated in the open, trade-offs settled, leaders in the room and deciding. The reality in plenty of organizations: the plan was locked before anyone walked in, the breakouts are transcription, the vote is a suspiciously uniform four, and the applause is scheduled. That's not planning. That's a very long announcement.

And the fatigue is real. Two 8-to-5 days of negotiating, on your feet or on a nine-hour video call, drain people in a way sprint planning never does. When your teammates dread the event, treat that as data. It usually means the last plan didn't survive sprint one.

How to tell a real one from a performance

Four markers separate the real thing from the performance, and you can check all four from your chair.

• A decision happened in the room. You can point at the moment the plan changed because two people talked. If every conflict went offline, the room decided nothing.

• Scope actually moved. Something got cut, traded, or pushed between draft and final. A plan where nothing came off isn't a plan. It's a wish list with dates.

• Dependencies have first names. "Platform will provide the API" is decoration. "Priya, by sprint two, and she was in the conversation when we agreed" is a commitment.

• The plan survives contact with sprint one. A real plan bends in sprint one. A fake one gets abandoned. If the last three PI plans died by sprint two, that's not a planning problem. It's a truth problem.

Walking into your first one

Here's the survival guide I sent her. Four situations, four moves.

Before you go

Refine your backlog enough to plan against, and know your team's honest capacity: subtract the vacations, the support rotation, the new joiner still finding the coffee machine. Read the top ten features in advance. Day one's morning should feel like confirmation, not news.

At the board

Your job, especially as the Scrum Master, isn't to have answers. It's to make invisible things visible. Three sentences worth taping to your laptop: "That's a dependency, let's string it now." "Who exactly owns that on your side?" "We're at capacity, so if this comes in, what goes out?" You'll feel like you're being difficult. You're being the one person doing the event's real job.

When the other team shrugs

Sooner or later your dependency lands on a team that says "we'll try to squeeze it in." Don't accept the shrug, and don't pick a fight at their board. Make it public instead. The string goes up anyway, marked uncommitted, and it goes to the risk wall by name: our feature depends on work nobody has committed to. Now it's the program's problem in daylight, not your private surprise in week six. That isn't politics. That's the mechanism working as designed.

When the vote should be low

If you genuinely can't see the plan working, hold up two fingers and say why. A low confidence vote isn't an insult to whoever built the plan. It's the cheapest correction your program will ever get: ten awkward minutes now, against twelve wasted weeks later. The whole ritual exists to make that honesty affordable. Spend it.

What the two days buy

My mentee messaged me the evening after her first one. "Day one was chaos. Day two was weirdly great? We killed a feature and nobody died." That's roughly the best review PI planning ever gets.

The plan itself will bend by sprint two. It's supposed to. What you're buying, when the event is real, is a program full of people who've seen the same board, argued over the same strings, and put their names next to the same risks. Ten teams walk in with ten plans. One program walks out with one.