Whimsical LogoWhimsical LogoWhimsical Logo

Brand
Get all logo versions.
Download

PI Planning Template

PI planning is the SAFe ceremony where every team on an Agile Release Train plans the next Program Increment together, typically 8 to 12 weeks of work. The artifact it produces is a PI roadmap, and that's what this template is: three PI columns holding epics, features, and capabilities, with milestone and release markers between them. RTEs and program teams use it to plan the increment and keep the roadmap current afterward.

A SAFe PI roadmap: three increments of epics and features with milestones and releases.

What's included

  • Three PI columns. PI 1, PI 2, and PI 3 as card stacks; add more for a longer horizon.
  • Typed work cards. Epic, Feature, and New Capability cards matching the SAFe backlog hierarchy.
  • Milestone and release markers. Diamond shapes between increments mark the fixed dates everything plans around.
  • Rich card content. Example cards show checklists to tick off, links and embeds for context, even code blocks.
  • A persistent roadmap. The board outlives the planning event, so stakeholders read the current plan instead of asking for it.

Why use a PI planning template?

  • The whole train on one board. Fifty to a hundred people plan against the same three columns instead of eight private Jira views.
  • Cheap to rearrange. Dragging a feature from PI 2 to PI 3 during a breakout takes a second; replanning a tool takes a meeting.
  • Milestones stay visible. Fixed dates sit between the increments, so capacity arguments happen against the real calendar.
  • Works remote and async. Distributed ARTs run the two-day event on a shared board and keep using it afterward.
  • Hierarchy without ceremony. Epics, features, and capabilities are just typed cards; no admin setup before planning can start.

How to use this template

  1. Set the horizon. Three Program Increments is the SAFe-standard roadmap window: one committed, two forecast.
  2. Load the backlog. Add epic and feature cards from the program backlog, prioritized before the event (WSJF or whatever you use).
  3. Place the milestones. Put release and milestone markers on the board first; they're the constraints teams plan around.
  4. Run the breakouts. Teams pull features into the PI they can deliver, splitting them into stories in their own plans.
  5. Surface dependencies and risks. Mark cross-team dependencies as the breakouts expose them, and ROAM the risks before the confidence vote.
  6. Keep it alive. After the event, the board is the PI roadmap; update it as features move and the next planning starts from reality.

PI planning vs sprint planning

Sprint planning and PI planning are the same instinct at different scales. Sprint planning: one team, one or two weeks, tasks pulled from a backlog, an hour or two in a room. PI planning: an entire Agile Release Train, 8 to 12 weeks, features negotiated across teams, two full days with a confidence vote at the end. The PI sets the frame, then the sprints fill it in. If sprint planning keeps surprising you with cross-team dependencies, that's the gap PI planning exists to close.

Frequently asked questions

  • PI planning is the Scaled Agile Framework's cadence-based planning event: all teams on an Agile Release Train (typically 50 to 125 people) come together, usually for two days, to plan the next Program Increment. Teams review the vision and backlog, break features into their own plans, map dependencies, and commit to PI objectives, ending with a confidence vote on the whole plan.

  • A Program Increment (PI) is SAFe's planning container: a fixed timebox of 8 to 12 weeks holding four to five iterations plus an Innovation and Planning iteration at the end. It's the train-level equivalent of a sprint: teams iterate inside it, and the whole ART plans, demos, and inspects at its boundaries. This template's columns are PIs; the cards are the epics and features inside them.

  • Scope and altitude. Sprint planning is one team deciding what fits in the next one to two weeks. PI planning is every team on the release train aligning on the next 8 to 12 weeks: shared objectives, cross-team dependencies, and fixed milestones. Sprint planning happens roughly ten times per PI; PI planning happens once, and the sprint plans live inside the frame it sets.

  • The standard event is two days, on a cadence of every 8 to 12 weeks. Day one covers business context, vision, and a first round of team breakouts ending in a draft plan review. Day two runs a second breakout round, risk ROAMing (resolved, owned, accepted, mitigated), the final plan review, and a confidence vote; SAFe's bar is an average of at least three on a fist of five.

  • A PI roadmap is delivery-facing: it shows what each team ships in the current and next two Program Increments, with milestones and releases pinned to dates. A product roadmap is outcome-facing: it communicates direction to stakeholders without committing teams to dates per feature. The PI roadmap is the contract the train just planned; the product roadmap is the story the product is telling.