Sprint Planning Doesn't Need Everyone in the Room

Published: at 08:09 PM

Table of contents

Open Table of contents

The two-hour room full of people who’d rather be coding

Every sprint planning session I’ve ever attended followed the same script. Ten people file into a room (or a Zoom grid). The Product Manager shares their screen. The backlog scrolls by. Tickets get estimated, assigned, discussed, and re-estimated. Two hours later, everyone stumbles out with a plan they’ll abandon by Wednesday.

Here’s the uncomfortable question nobody asks: did all ten of those people need to be in that room?

The answer, in most teams I’ve observed, is no. Sprint planning has become a democracy where everyone gets a vote — even the people whose votes are uninformed, disengaged, or actively counterproductive. It’s the team-level version of design-by-committee, and it produces the same bland, compromised results.

Team working around a table
Bigger rooms don't produce better plans. They produce longer meetings. Photo by Headway on Unsplash.

Who actually needs to be there?

Let’s be honest about what sprint planning actually requires:

You need someone who knows what to build. That’s the Product Manager or whoever owns the roadmap. They bring priorities, context, and the “why” behind each item.

You need someone who knows how to build it. That’s usually a tech lead or senior engineer who understands the system well enough to spot hidden complexity, dependency chains, and technical risks before they become mid-sprint surprises.

You need the people who will build the risky or ambiguous items. If a ticket involves a new database schema, the engineer owning it should be in the room. If it’s a standard CRUD endpoint on a well-understood pattern, they don’t need to be.

That’s three to four people, tops — not ten. The rest of the team gets briefed afterwards, asynchronously, in ten minutes of reading instead of two hours of sitting.

The goal isn’t fewer meetings for the sake of fewer meetings. It’s the right people in the right meetings, and nobody else.

What the “everyone in the room” model actually costs

Two hours. Ten people. That’s twenty engineering hours per sprint. Across twenty-six sprints a year, it’s 520 hours — thirteen working weeks of one person, gone.

And that’s just the visible cost. The hidden costs are worse:

The cascade effect. Sprint planning isn’t a floating two-hour block. It anchors the day. People who attend at 10am lose their morning flow. By the time they recover context and get back into deep work, it’s lunch. Half a day, gone.

The engagement drain. When you’re in a meeting where 80% of the discussion doesn’t concern you, you disengage. You check Slack. You read emails. You become a warm body in a chair — present but not contributing. Now multiply that by eight people, every two weeks, indefinitely.

The false consensus problem. When everyone estimates a ticket, you get the average of everyone’s understanding — including people who haven’t read the spec. A tech lead who knows the system might estimate two days. A junior engineer who hasn’t touched that module might guess five. The average is three and a half. It’s not more accurate than the tech lead’s estimate. It’s just louder.

How alignment should actually work

Alignment — the real goal of sprint planning — doesn’t come from putting everyone in a room together. It comes from making sure the right information flows to the right people at the right time. Here’s what that looks like in practice.

The focused planning session (45 minutes, 3-4 people)

Once per sprint, the PM, tech lead, and any engineers owning complex items meet for forty-five minutes. The agenda is specific:

  1. What’s the most valuable thing we can ship this sprint? This is the PM’s call, informed by the tech lead’s reality check on feasibility.
  2. Which items carry technical risk? Flag anything involving new services, unfamiliar patterns, or cross-team dependencies. These get assigned to specific people during the session.
  3. What’s the capacity ceiling? Not story points — real, human-acknowledged capacity. “Priya is on call this week, so she’s at half capacity. David is wrapping up the auth migration — don’t load him with new work.”

That’s it. No estimates. No trying to fill every available hour with tickets. The output is a prioritized list of work with known owners for the risky items — not a minute-by-minute schedule.

The async brief (10 minutes to read, posted after the session)

The three or four people who attended write up a brief — five or six bullet points in a shared document or Slack channel. It covers:

The rest of the team reads it on their own time. If they have questions, they ask in the thread. If they spot a dependency the planning group missed, they flag it. This async layer catches the edge cases without pulling eight people into a room for two hours.

The weekly alignment check-in (15 minutes, whole team)

Mid-sprint, the whole team gathers for fifteen minutes — not to report status, but to sync on changes. Three questions:

  1. Has anything shifted that the team should know about?
  2. Is anyone blocked or heading toward a block?
  3. Does anyone need help from someone outside their immediate pair?

This replaces the daily standup and the sprint review combined. It’s short because it has a narrow purpose: surface changes, not recaps. If nothing has changed, the meeting ends in five minutes.

What you lose (and why it’s fine)

When you stop putting everyone in sprint planning, you lose a few things. Most of them aren’t worth keeping.

You lose the ritual of collective estimation. Good. Collective estimation without full context produces bad estimates that become commitments nobody feels accountable for.

You lose the illusion that everyone has equal input. Also good. Experience and context aren’t evenly distributed across a team, and pretending they are doesn’t make planning better — it makes it slower.

You lose the “team bonding” of a shared ritual. This one is real, but there are better rituals. Team lunch. A demo hour where people show what they built. A retro that actually discusses process instead of updating a board. You don’t need a planning meeting to feel like a team.

What about cross-team alignment?

The model gets more complex when your work spans multiple teams. But the principle holds: only the people who need to coordinate should be in the coordination meeting.

For cross-team work, we use a “representative” model. Each team sends one person — usually the tech lead or the engineer most involved in the shared work. They meet for thirty minutes, resolve dependencies, and brief their respective teams async. The full cross-team planning session (with fifteen people in a room for three hours) is a symptom of organizational design, not a requirement of good planning.

The team I ran this with

I didn’t kill sprint planning. I shrunk it. We went from ten people in a room for two hours to three people in a room for forty-five minutes. The rest of the team gets briefed async and shows up for the fifteen-minute mid-sprint check-in.

The results after three months:

The team didn’t become less aligned. They became more aligned, because alignment now flows through written briefs and focused check-ins instead of two-hour marathons where half the room wasn’t paying attention.

Try it for one sprint

Don’t take my word for it. Run the experiment:

  1. Next sprint planning, invite only the PM, tech lead, and engineers owning risky or ambiguous items. Keep it to 45 minutes.
  2. Post a written brief afterwards and ask the rest of the team to read it and raise questions async.
  3. Run one fifteen-minute mid-sprint check-in with the full team.
  4. At the end of the sprint, ask everyone: was the plan better, worse, or the same? Did you feel less informed, more informed, or the same?

I’d bet on “better” and “more informed.” And if I’m wrong — if your team genuinely thrives on the two-hour room with everyone present — keep doing it. But at least you’ll know, instead of assuming it’s the only way because it’s the way you’ve always done it.