PI Planning overview
What this page is — The map of PI Planning: several teams plan one programme increment (a phase of a project and the sprints under it) together, each on its own board, against one shared clock, and the result is merged and committed to the tasks once. What it is for — Running a multi-team planning event — "big room planning" — inside Orbit instead of on sticky notes, spreadsheets and a video call, and ending it with a plan that is already written to the tasks. The problem it solves — When three or four teams plan the same quarter, the single-planner Planning page does not fit: everyone would edit one scenario, everyone would see everyone's capacity, and whoever may move a card may also commit. PI Planning gives each team its own board and people, keeps the facilitator in charge of the clock and the commit, and makes cross-team dependencies, risks and objectives visible to the whole room.
Route: /org/tasks/pi-planning · Permissions: see Who can do what below — the role editor lists them under the PI Planning module
Module: PI Planning, in the Task Management category · Entry points: Sidebar → PI Planning · Quick create → New PI session · Cockpit → PI Planning tile · global search ("PI Planning", "Program board", "Risks (ROAM)", "Discussion") · the in-app Docs button
1. What PI Planning is — and how it relates to Planning
A session is one planning event for one project. It names a PI — a phase of the project whose sprints become the session's iterations — the teams that take part, a facilitator, and an agenda (a length, breaks and collaboration slots). When the session is published, every team gets its own board: an ordinary Planning scenario that holds only the tasks of the categories that team plans, and only that team's people in capacity. At the end the facilitator merges the team boards into one program plan and commits it with Planning's own commit.
| Planning | PI Planning | |
|---|---|---|
| Who plans | One planner (or a few) on one scenario | Every team on its own board, at the same time |
| Work on the board | Every open task of the project | Only the categories (or single tasks) given to that team |
| Capacity | The whole project roster | Only the team's own people; shared people counted once when merged |
| Moving a card | Needs the Planning manage permission — which also commits | Needs the PI Planning team member permission and membership of that team; committing is separate |
| Time | Open-ended | A shared countdown with breaks and collaboration slots |
| Around the plan | Goals per time box | Discussion, broadcasts, ROAM risks, PI objectives with business value, cross-team dependencies, demos, a confidence vote |
| Commit | One scenario, one commit | All team boards merged, then one commit — the same preview, the same checks |
Both pages stay available. A project can plan one quarter with PI Planning and do day-to-day sprint re-planning on the Planning page; both write the same tasks, and a committed PI plan appears in Planning's commit history like any other commit. Team boards and the program plan never show up in the Planning page's scenario switcher.
2. Why you would use it
- One event instead of a week of meetings. Teams plan in parallel, dependencies are raised and answered in the room, and the plan is committed the same day — no one re-types a whiteboard into tasks afterwards.
- Each team plans only what is theirs. A team sees its own categories and its own people's capacity, so load bars mean something and nobody drags another team's work by accident.
- Dependencies become commitments. A cross-team link is proposed by one team and accepted by the other team's lead; only accepted links become task dependencies at commit.
- Risks and confidence are on the record. ROAM risks, PI objectives with business value and the confidence vote stay with the session, so the next PI starts from what the last one learned — including a predictability figure.
- The commit stays with a person who may commit. Facilitating does not mean writing tasks: the commit also needs Planning's commit permission.
3. The life of a session — step by step
| Pip | Control | What it does |
|---|---|---|
| 1 | New PI session | Opens the session drawer — see Session and brief. Only with the permission to create sessions |
| 2 | Session card | Name, status, the PI with its dates, the teams (with their colours), the facilitator, the session length, and the round when an adjustment round ran. Click to open |
| 3 | Settings gear | Project settings → PI Planning: default length and facilitator, the confidence vote, and the teams that plan here — see Teams |
| 4 | Show closed | Adds closed and abandoned sessions to the list (they are hidden by default) |
A session moves through these statuses. The status chip in the session bar shows it at all times, and it decides what anyone can do:
| Status | What happens | Who moves it on |
|---|---|---|
| Draft | The facilitator sets up the PI, the teams, the agenda, and which team plans which category | Publish — facilitator or session manager |
| Briefing | Every team has its board; everyone reads the brief and the links. Posts and objectives are open, boards are not yet | Start planning — facilitator |
| Planning | The clock runs. Teams move cards on their own boards, raise risks, propose dependencies, post questions | End planning — facilitator |
| Review | Boards freeze. Teams demo, everyone votes their confidence, the facilitator merges and commits | Adjust (back to planning for a shorter round) or Merge & commit |
| Adjusting | An adjustment round: boards open again with a new, shorter clock; votes start fresh | End planning — back to Review |
| Committed | The merged plan is written to the tasks. Objectives can be scored after the PI | Close |
| Closed | Finished, read-only. An abandoned session is also closed — without writing anything | — |
Step by step, a typical event:
- Once per organisation — create the teams in Organization Settings → Planning Teams and link them to the project (Teams).
- A week before — create the session, pick the PI phase, the teams and the agenda; on the Brief tab give every category in the PI to a team and add the briefing links; Publish (Session and brief).
- On the day — the facilitator presses Start planning; teams plan on the Team boards tab, post on Discussion, raise Risks and propose dependencies on the Program board (Live session, Program board and risks).
- At the end — End planning, demos and the confidence vote on Review, then Merge & commit (Review, merge and commit).
- After the PI — score each committed objective's delivered value to get the predictability figure.
4. Who can do what — field reference for the permissions
The role editor lists these under the PI Planning module, by their description. The bold text is how each description begins — type it into the role editor's search box to find it.
| Permission (role editor text begins…) | Lets a person | Typical holder |
|---|---|---|
| Show the PI Planning sidebar entry. | See PI Planning in the sidebar | Everyone who takes part |
| Open PI Planning sessions read-only | Open any session of a project they can open, follow it as an observer; see the cockpit tile | Stakeholders, business owners |
| Take part in a PI session as a team member | Move cards on their own team's board, post, raise risks, propose cross-team dependencies, write their team's objectives, demo and vote | Team members |
| Run a PI session | Facilitate any session: the clock, breaks, broadcasts, allocations, conflicts, combining risks, adjustment rounds and the merge | Release train engineers, delivery leads |
| Create, edit and close PI sessions | Create sessions, choose the teams, hand a session to another facilitator, abandon a session, edit the project's PI Planning settings | Programme managers |
Three rules sit on top of the permissions:
- The named facilitator runs their own session. Whoever is picked as a session's facilitator may run that session with only the team-member permission.
- Team membership decides which board you can change. A team member can move cards only on the board of a team they belong to (Organization Settings → Planning Teams); every other board is read-only for them. The facilitator can move cards on any board.
- Committing needs Planning's commit permission as well. The merge's Commit the PI plan button also needs the Planning permission that begins Create and edit scenarios, move and assign tasks on the board — the one that governs every commit to real tasks.
Teams themselves are governed by three permissions in the Planning Teams module: Show Planning Teams in the Organization Settings hub., See the organisation's planning teams and Create, edit and deactivate planning teams.
PI Planning comes with the Orbit Ops task-management package; when your package includes task management, the module is available and only the permissions above need granting.
5. The cockpit tile
Anyone who may open PI Planning sessions sees a PI Planning tile on the cockpit, for the projects they belong to:
- Active session / Next session — the session being planned, reviewed or adjusted (or the next one to start), with its project, status and start. Click to open it.
- Active sessions — sessions not yet committed or closed.
- Open risks — ROAM risks still open in those sessions (risks already combined into a programme risk are not counted). Shown in red when above zero.
- Unmerged teams — team boards not yet merged into a program plan.
- Committed · 30 days — sessions committed in the last 30 days.
6. Worked example
The Optima Orbit project plans PI 2026.4 (5 Oct – 13 Nov, three two-week iterations) with three teams: Payments (checkout, invoices, refunds), Mobile (the apps) and Platform (the public API and gateway). One scrum master works for both Payments and Mobile at 50% each.
A week before, the delivery lead creates the session with an 8-hour agenda — coffee at +90 minutes, a dependencies sync at +180, lunch at +240 — gives Orbit Books to Payments, Orbit Mobile App to Mobile and the two API categories to Platform, adds the vision deck and the architecture runway as briefing links, and publishes. Each team's board now holds only its categories' open tasks.
On the day she starts the clock. Mobile's lead needs the refund API before the in-app checkout can ship, so he proposes a dependency on the Payments task; the Payments lead accepts it. Mobile and Payments each raise a risk about the same gateway vendor; the facilitator combines them into one programme risk, owned. At 16:00 she ends planning: two teams demo, the room votes 3.5 on average, she merges — 189 tasks from three teams, one cross-team link, one conflict decided — and, with Planning's commit permission, commits once. Every task gets its iteration, assignee and estimate; the refund dependency is on the tasks; the PI phase's goal reads "Customers can pay and get refunds from the mobile app".
7. The admin contract
- Teams must exist and be linked to the project (Organization Settings → Planning Teams, or Project settings → PI Planning). A session can pick only active teams linked to its project.
- Team members must be members of the project. Work cannot be assigned to someone who is not on the project; the Brief tab lists such people under Not on the project, and the commit refuses an assignment to them.
- The PI must be a phase with sprints under it on the project Roadmap. A phase with no sprints cannot be picked.
- The project needs task categories — categories are how work is split between teams. Tasks with no category can be given to one team as a whole.
- Permissions as in §4, including Planning's commit permission for whoever commits.
- Notifications: the broadcast and committed e-mails use the templates PI Planning Broadcast and PI Planning Session Committed, editable like any other e-mail template.
8. Don't confuse this with…
- Planning workspace — one planner, one scenario, the whole project. Use it for ongoing sprint re-planning; use PI Planning for the multi-team event. Both commit the same way.
- Scenarios and commit — the commit review you see at the end of a PI session is Planning's commit review, run on the merged plan.
- Dependencies — dependencies inside one board. Links between two teams' boards are proposed and answered on PI Planning's Program board.
- Planning Teams vs project members — a planning team is a standing group of people across projects; project membership decides who can be assigned. A team member still has to be a project member.
9. Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| No PI Planning in the sidebar | The role lacks Show the PI Planning sidebar entry., or the package does not include task management | Grant the permission; check the package |
| "You do not have access to PI Planning" | The role lacks Open PI Planning sessions read-only | Grant it |
| "Pick a project" | No project is selected in the header | Pick the project — sessions belong to a project |
| No New PI session button | The role lacks Create, edit and close PI sessions | Grant it, or ask a programme manager to create the session |
| The sessions list says "First, link the teams that plan in this project" | No team is linked to the project | Link teams under Project settings → PI Planning |
| A finished session is missing | Closed sessions are hidden | Show closed |
| No PI Planning tile on the cockpit | The role lacks the read-only permission, or you are not a member of the session's project | Grant the permission; the tile counts your projects only |
| "You are following this session as an observer" | You are neither in one of the session's teams nor its facilitator | Ask to be added to a team (Planning Teams), or named facilitator |