Two days, one room, every team on the wall — that's how PI Planning was designed. For most ARTs it hasn't looked like that in years. Teams sit in three cities, one team sits at a supplier, two people are at home. Distributed PI Planning is the norm now, not the exception.
Most advice about it stays on the surface: "use Miro," or generic remote-meeting tips that apply to any video call. The more useful question is a different one — what exactly is lost when the ART isn't in one room, and what can replace it?
The short version: the hard part of remote PI Planning isn't the tooling for the ceremony. It's that remote removes the informal bandwidth — and that's where most dependencies used to surface. Replace it deliberately, or you get a plan that works on paper and falls apart in the first sprint.
What genuinely changes
Three things change substantially. The rest is logistics.
The hallway conversations disappear. In an on-site planning event the most valuable insights happen in the breaks: someone walks past another team's board, sees a feature and says "wait, that needs our API." Those accidental discoveries aren't a by-product of the ceremony, they're a core part of it. Remote, they simply stop happening. Dependencies that used to reveal themselves now have to be actively hunted.
Attention span halves. Eight hours on a video call is not eight hours in a room. After roughly three hours participation drops measurably — cameras go off, email gets read in parallel, and the quiet people get quieter. Port the on-site agenda unchanged into Zoom and you're planning the second half of each day with half a crew.
The artifact matters more than the discussion. In a room you can point at a board. Remote, the plan only exists to the extent that it's been made visible. A photo of a whiteboard helps nobody who wasn't in the session — and certainly not three weeks later, when half the assumptions have changed.
Preparation matters more than facilitation
Distributed planning shifts the weight decisively forward. What could once be sorted out spontaneously in the room now has to be settled beforehand — otherwise you burn scarce shared time on cleanup.
The backlog has to be plannable, not merely present
Features estimated, hierarchy clean, epics mapped to features. If you're still debating whether something is a feature or a story on the day, you lose the first half-session. A CSV export from Jira a few days ahead makes those gaps obvious immediately — the guide to PI Planning with Jira Standard covers how.
Capacity is settled before the session starts
Velocity per team, holidays, public holidays, onboarding overhead, IP sprint. Working these out during the planning event is wasted time — collect and share them beforehand. The rule of thumb holds: plan 70–75% of theoretical capacity for new features.
A pre-read instead of a live presentation
Send business context and product vision as a document or recorded video two to three days ahead. The session then needs 20 minutes for questions instead of a 90-minute presentation nobody has their camera on for.
The format: shorter, more often, stricter
The pattern that works most reliably for distributed ARTs isn't "two days online" — it's four half-days instead of two full days. Plan in the mornings; teams keep working in their own time zones in the afternoons. It costs two more calendar days and rescues the quality of the second half.
What concretely helps:
- Fixed timeboxes, firmly facilitated. Overrunning is more expensive remote than in a room, because fatigue arrives sooner. A visible running timer works surprisingly well.
- Team breakouts in their own calls, with a fixed return time. Not "ping us when you're done" — a specific moment when everyone is back.
- Explicit dependency rounds. The single biggest difference from on-site planning: each team presents its draft plan briefly and actively names what it needs from whom. Don't rely on dependencies surfacing by themselves — remote, they don't.
- One person holds the whole picture. Somebody maintains the program-level plan in one place everyone can see. Otherwise you end up with six team plans and no PI plan.
- A backchannel for interruptions. A chat channel where "our feature depends on yours" can be said at any point without breaking the flow. It's the closest available substitute for the hallway conversation.
Tools — and where they stop helping
Whiteboard tools like Miro and Mural represent the ceremony well: sticky notes, dependency strings, everyone working at once. For the two days themselves they're a sensible choice, and most distributed ARTs use them for good reason.
Their weakness starts afterwards. A whiteboard doesn't know your capacity, doesn't recalculate anything, and has no connection to your Jira data. Move a feature two sprints out and nothing tells you which sprints now overflow — you have to track that yourself. And because that's tedious, it mostly doesn't happen: the plan stays in the state the session left it in, and goes stale from day three.
This is exactly where the tool for the ceremony parts ways with the tool for the plan. The ceremony needs a shared surface. The plan needs something that knows capacity, represents dependencies, and can be updated without someone dragging 40 sticky notes by hand. We wrote up the options in the comparison of Advanced Roadmaps alternatives.
After planning: the plan has to outlive the session
This is where distributed PI Planning most often fails — and it has nothing to do with the ceremony any more.
On site, the program board hangs on a wall people walk past every day. Remote, that wall doesn't exist. If the plan ends up as a screenshot in a Confluence page, nobody looks at it after the first week, and the next PI Planning starts from zero again.
What helps is unglamorous: the plan needs a format that can be changed and stays shareable. When a sprint review reveals a feature will land two sprints later, making that adjustment should take minutes and show the knock-on effect for the other teams — not half an hour of manual work in a spreadsheet.
A practical test: two weeks after planning, ask how long it would take to move a slipped feature in the plan and show every affected team the consequence. If the answer is more than ten minutes, it won't happen during the real PI.
Conclusion
Distributed PI Planning works — but not by copying the on-site agenda into a video tool. The three levers that make the difference: pull preparation forward so shared time is spent planning; shorten the days and ask for dependencies explicitly instead of hoping they surface; and produce a plan that outlives the session.
The tool for the ceremony and the tool for the plan are allowed to be different ones. Just don't count on a whiteboard doing both.
Don't lose the plan in sticky notes
ROADagile turns your Jira CSV into a capacity-based PI roadmap with dependencies — in the browser, without a plugin, without your project data leaving your machine. Take a look at the live demo, or join the mailing list.
Join the mailing list