How to Run PI Planning in Miro
Program Increment (PI) Planning is the heartbeat of the Scaled Agile Framework: a two-day event where multiple teams plan the next 8-12 weeks of work together, surface dependencies, identify risks, and commit to a program increment objective. Running PI Planning for distributed teams requires a digital canvas that replicates the physical sticky-note walls of in-person sessions — and Miro is purpose-built for this.
This guide covers setting up a Miro PI Planning board, facilitating team breakouts, mapping cross-team dependencies, and capturing the PI objectives and risk board that constitute the event deliverables.
Step-by-step guide
Set up the PI Planning board structure before the event
Create a new Miro board titled "PI Planning — [PI Number] — [Dates]." Use Miro Frames to organize the board into sections: Program Board (center), Team Breakout frames (one per team, labeled with team name), Risk Board, PI Objectives Board, and Parking Lot. Pre-populate the Program Board with a calendar grid showing the sprints of the PI (typically 5 two-week sprints). Use table columns for each sprint and rows for each team.
Pre-load the program backlog into the board
Before PI Planning, product management adds the top features and enablers to the Program Board as sticky notes. Color-code by type: blue for features, green for enablers, orange for spikes. Each sticky should contain: Feature name, WSJF score (Weighted Shortest Job First), and the team responsible. This gives teams the starting context without reading a 50-slide deck at the start of day one.
Run team breakout sessions using dedicated frames
During day one afternoon breakouts, each team works in their own Miro frame. They take the features assigned to them and break them into user stories, assigning stories to sprints using sticky notes in the team's PI Planning grid. Each story sticky should have: story name, story points estimate, and owner. Set a timer in Miro (clock icon in the toolbar) for 90-minute breakout sessions.
Map cross-team dependencies on the Program Board
After breakouts, bring teams back to the Program Board. Each team places a red dependency sticky on the Program Board wherever they depend on another team's output. Draw a connector arrow from the dependency sticky to the story it enables. The Program Manager reviews all dependency arrows for conflicts: dependencies that create scheduling risks (one team's output is needed before another team's sprint starts) get a red X overlay.
Run the ROAM risk session
Create a ROAM Risk Board frame in Miro with four quadrants: Resolved, Owned, Accepted, Mitigated. Teams submit risks as sticky notes during day two. The Release Train Engineer (RTE) facilitates ROAMing each risk: the group decides which quadrant it belongs in. Unresolved risks that belong in "Accepted" need an owner assigned before the session closes. Use Miro's voting feature to prioritize the riskiest items.
Capture PI Objectives and confidence vote
Each team creates their PI Objectives in their team frame: a list of 3-5 business outcomes they commit to delivering in the PI, with stretch objectives noted. The final activity is the confidence vote: each team member places a sticky with a number (1-5) on the PI Objectives Board. Average below 3 means replanning is needed. Miro's anonymous voting feature (three dots > Voting) works for this if teams prefer anonymity.
Common mistakes
Starting the board setup during PI Planning
A PI Planning Miro board takes 2-4 hours to set up correctly. Create the board, add frames, pre-load the program backlog, and test the video conferencing integration the day before. Participants waste time if they spend the first hour waiting for the facilitator to set up the board.
Too many people in the same Miro frame simultaneously
More than 10 people editing the same frame simultaneously causes lag and accidental moves. During all-hands sessions, have most participants view (not edit). Only team representatives should edit during the program board session.
Dependency arrows that are never reviewed
If dependency arrows are drawn but never reviewed by the Program Manager for conflicts, the dependency mapping exercise adds no value. Assign one person to review all arrows after they are placed and flag conflicts before the end of day one.
No capture of PI Planning outputs to a permanent artifact
The Miro board is a great facilitation surface but a poor long-term reference. At the end of PI Planning, export the PI Objectives, Program Board snapshot, and ROAM Risk Board to Confluence or Notion as the permanent record. Update this artifact each sprint with progress.
Tips
Use Miro's Frames feature to create a table of contents on the board — participants can navigate to their team frame without scrolling the full canvas
Lock the Program Board frame so only PMs and the RTE can edit it — prevents teams from accidentally moving other teams' stickies
Use Miro's video embed to display the PI Planning video call in a corner of the board so participants can toggle between the call and the board without switching windows
Take a snapshot of the Program Board at the end of each sprint and store in Confluence to track how the PI plan evolved versus actuals
How Vantage helps
Vantage's dependency graph shows cross-ticket dependencies for all tickets in a project. Before PI Planning, export this dependency graph from Vantage to give teams a head start on identifying cross-team dependencies — reducing the dependency-mapping portion of day two from 90 minutes to 30.