Skip to main content

Session set-up, brief and team boards

What this page is — Everything that happens before and around the planning itself: creating a PI session, the Brief tab where the facilitator decides which team plans which category, publishing, and the Team boards tab where each team plans its own work. What it is for — Getting every team to walk into the room with its own board already filled with exactly its own work, its own people's capacity, and the same briefing material. The problem it solves — A planning event where the first hour is spent arguing about whose tickets are whose, or where every team sees the whole backlog, wastes the most expensive hour of the quarter. Deciding the split up front — and seeing conflicts before they matter — lets the teams start planning the moment the clock starts.

Route: /org/tasks/pi-planning?project=<project>&session=<session>&tab=brief · …&tab=boards&team=<team> · new session: /org/tasks/pi-planning?action=new-session Permissions: Create, edit and close PI sessions (create a session) · Run a PI session or being the named facilitator (edit, allocate, publish, decide conflicts) · Take part in a PI session as a team member (plan on your own team's board) · Open PI Planning sessions read-only (read everything) Module: PI Planning · Entry points: New PI session on the sessions list · Quick create → New PI session · the pencil in the session bar · the Brief and Team boards tabs

1. Session, brief and board — how they fit together​

The session holds the frame: the PI, the teams, the facilitator and the agenda. The Brief holds the split of work: every task category in the PI goes to one team, single tasks can be given to another team, and tasks with no category can go to one team as a whole. Publishing turns the split into boards: each team gets a board holding the open tasks of its categories — those already in the PI's iterations and those in the backlog — with capacity counted for its own members only.

Before publishing (Draft)After publishing (Briefing onwards)
Teams and PICan changeFixed
Name, facilitator, agendaCan changeCan change until committed
Category → teamCan changeCan change in Briefing and in an adjustment round; the tasks move between boards and keep where they were planned
Team boardsNot created yetOne per team; editable while planning or adjusting
IterationsThe phase's current sprintsFixed at the moment of publishing

2. Why you would use it​

  • Teams start planning immediately. Each board is pre-filled with the team's own categories, in the iterations and the backlog.
  • Load bars you can trust. A team board counts only its members, so "Under 31%" means this team has room.
  • Problems surface a week early. The Brief lists tasks on two boards, people in two teams, planned work nobody owns, and team members who are not on the project — while there is still time to fix them.
  • One source of briefing material. The vision, the architecture runway and the executive brief are linked on the session, not scattered across mails.

3. Create a session — step by step​

Figure 1 — New PI session: 1 the PI, 2 facilitator, 3 teams, 4 agenda with breaks and collaboration slots.
  1. On the sessions list press New PI session (or Quick create → New PI session).
  2. Type a Name, for example PI 2026.4.
  3. Pick the PI — a phase of the project. The list shows each phase with its number of sprints; a phase with no sprints cannot be picked.
  4. Check the Facilitator (pre-filled from the project's default).
  5. Untick any Team that does not take part. All linked teams are ticked to start with.
  6. Set the Agenda: the length in minutes, then Add a break and Add a collaboration slot as needed.
  7. Create session. The session opens on its Brief tab, in Draft.

Field reference — the session drawer​

FieldControlRequiredValidation and where values come from
NameTextYesUp to 120 characters. Unique among the project's sessions that are not closed — "That name is already used" otherwise
PI (a phase of the project)Searchable selectYes, in DraftThe project's phases from the Roadmap, shown as title — n sprints. Its sprints become the iterations. Locked after publishing
FacilitatorSearchable selectNoThe project's members. Pre-filled from Project settings → PI Planning, else the creator. Changing it later needs Create, edit and close PI sessions
TeamsA toggle per team, with n people and n not on the projectAt least one, in DraftThe active teams linked to the project. Link teams to this project opens the project settings. Locked after publishing
Agenda — lengthNumber, minutesYes15 minutes to 3 days (4,320). Pre-filled from the project default
BreaksRows: title · starts after (min) · length (min) · removeNoA new row is titled Break, 15 minutes, placed after the last slot
Collaboration slotsSame rowsNoTime set aside for teams to sort out dependencies together; a new row is titled Cross-team sync, 30 minutes

Agenda rules, checked when you save: every break and slot needs a length; each must end inside the session length ("… ends after the session does"); breaks and slots must not overlap.

To change the session later, the facilitator (or a session manager) uses the pencil in the session bar: the same drawer, with the PI and the teams locked once published.

4. The Brief tab​

Figure 2 — The Brief tab of a draft session: 1 Publish, 2 the PI and agenda, 3 Who plans what, 4 the team per category, 5 briefing links, 6 conflicts.
PipAreaWhat it shows or does
1PublishDraft → Briefing. See §5
2The PIThe phase and its dates, one chip per iteration with its dates, the facilitator, the length and every break and slot with its start (+90 min)
3Who plans whatOne row per task category of the project: open tasks In iterations and in the Backlog
4TeamPer category: Not in this PI (left out), In this PI — no team yet, or a team. The last row, No category, decides who plans the tasks that have no category
5Briefing linksLinks teams should read first. Pick the kind (Vision, Architecture, Executive brief, Other), type a title and an https:// address, Add link. Saved at once; the bin removes one
6ConflictsWhat must or should be decided before merging — see below

Allocating, step by step:

  1. For each category that belongs in this PI, pick the team in the Team column. Leave the others at Not in this PI.
  2. Decide the No category row: a team, or leave it out.
  3. For a task that belongs to another team than its category's, type at least two characters in Find a task to give to a team…, pick the team beside it and click the task (+ give to Payments). It appears under Single tasks given to a team; the bin removes the override.
  4. Save allocation (or Discard). The buttons appear as soon as something changed.

The allocation can be changed by the facilitator or a session manager while the session is in Draft, Briefing or an adjustment round. After publishing, a category that changes team takes its tasks along to the new team's board, keeping the iteration and assignee they were planned with.

Conflicts and warnings​

Figure 3 — Conflicts on a published session: a task on two boards, and a person in two teams.
  • n tasks are on two boards — the same task sits on two team boards. The facilitator picks the team that keeps it; until then the category's team is the default. The merge needs every one decided (a default counts).
  • n persons are in more than one team — allowed. Their load from every team counts against one capacity on the Program board.
  • Planned work with no team — categories in the PI with no team yet, the number of open tasks that would not be planned, and the first 30 of them.
  • Not on the project — a separate card listing team members who are not members of the project; work cannot be assigned to them until they are added.

5. Publish​

Publish (facilitator or session manager, Draft only) asks Publish the session? — "Each team gets its own board, seeded with the tasks of the categories it plans, and everyone can read the brief. Teams and the PI cannot change after this." On Continue:

  • the PI's current sprints become the session's iterations (sprints added to the phase later are not added to the session);
  • each team gets its board: its categories' open tasks and its single-task overrides, in the iterations and in the backlog, with capacity for its own members;
  • the program plan is prepared for the merge, and the session moves to Briefing.

Publishing is refused, with a toast, when the PI is missing (Pick the PI (a phase) before publishing.), when the PI has no sprints (The PI phase has no sprints under it yet — add its iterations on the Roadmap first.) or when no team takes part. When a category is set to In this PI — no team yet, a second question follows — Publish with unallocated categories? — with Publish anyway: its tasks then stay off every board. Or cancel, give the category a team (or set it to Not in this PI) and publish again.

6. The Team boards tab​

Figure 4 — A team board: 1 the team strip, 2 conflicts, 3 whether you can plan here, 4 the team's goal per iteration; below it, the Planning board.
PipControlWhat it does
1Team stripOne button per team: colour, name, You on your own team(s) (listed first), the number of tasks on its board, and a green dot when someone of that team is online
2n conflictsAppears when tasks are on two boards; opens the Program board where they are decided
3Write statusYou can plan on this board. — or Read-only with the reason — and how many team members capacity counts
4Goal per iterationOne field per iteration: what this team will have done by its end. Saved when you leave the field. At merge the teams' goals are joined into each iteration's goal as Team: goal

Below is the same Plan board as the Planning page — the backlog, one column per iteration with its load bar and state (Under, OK, Over), cards with estimate, assignee and status, Plan by, Group by, filters, Card fields and Add task. Drag cards between the backlog and the iterations, assign, size and add tasks exactly as in Scenarios and commit. Every change stays on the team's board until the facilitator commits the merged plan.

Who can change which board:

  • A team member can move cards only on the board of a team they belong to, and only while the session is Planning or Adjusting.
  • The facilitator can move cards on every board.
  • Everyone else, and every board outside those two statuses, is read-only.
Figure 5 — The same board seen by another team's lead: 1 their own team comes first, 2 read-only.

On a phone the Team boards tab is not offered; the other tabs work read-mostly.

7. Worked example​

The delivery lead creates PI 2026.4 on the phase PI 2026.4 (5 Oct – 13 Nov, three sprints), keeps all three teams, sets 480 minutes with Coffee at +90 (15 min), Lunch at +240 (45 min) and a Dependencies sync collaboration slot at +180 (30 min).

On the Brief she sets Orbit Books → Payments, Orbit Mobile App → Mobile, Orbit Api Development and Orbit Architecture Shift → Platform, and everything else Not in this PI. She adds three links — Product vision — PI 2026.4 (Vision), Architecture runway: payment gateway v2 (Architecture), Executive brief — Q4 priorities (Executive brief) — and saves the allocation. Conflicts shows one person in two teams (the shared scrum master), which is fine. She publishes.

Payments' board now holds 76 open Orbit Books tasks, all in the backlog; Mobile's 69; Platform's 44. On the day, Payments puts five tasks into Iteration 1 with their assignees and 16 hours each and types the goal Refund API live in the sandbox. One Orbit Books task also turns up on Mobile's board, planned in Mobile's Iteration 2 — the Brief reports 1 task is on two boards, defaulting to Payments (the category's team); the facilitator confirms Payments, so Payments' placement is the one that is committed.

8. The admin contract​

  • Phases and sprints come from the project Roadmap. Create the PI phase and its sprints there first; sprints added after publishing are not part of the session.
  • Task categories are project settings. Every piece of work a team should plan must carry a category that is allocated, or be given to the team as a single task, or fall under the No category row.
  • Teams must be active and linked to the project (Teams); their members must be project members to be assigned work.
  • Planning settings of the project (estimation unit, focus factor, capacity ratios) apply to every team board, exactly as on the Planning page.

9. Don't confuse this with…​

  • Planning → New scenario — you choose time boxes and the backlog yourself; a PI team board is created for you from the allocation.
  • Planning → Capacity — the same capacity grid, but on a team board it counts only the team's members.
  • The Roadmap — where the PI phase and its sprints are created and dated. A session never changes the phase or its sprints' dates.

10. Troubleshooting​

SymptomCauseFix
The phase is greyed in the PI listIt has no sprintsAdd its sprints on the Roadmap
"Some planned categories have no team yet." on PublishA category is set to In this PI — no team yetGive it a team, or set it to Not in this PI
The PI or the teams cannot be changedThe session is publishedAbandon it and create a new one if they must change
No Save allocation buttonNothing changed yet, or the session is not in Draft, Briefing or an adjustment round, or you do not run the sessionChange a row; wait for an adjustment round; ask the facilitator
A team board is emptyNone of the team's categories has open tasks, or its categories were allocated elsewhereCheck Who plans what; give single tasks to the team
A sprint added yesterday is not on the boardsIterations are fixed at publishingPlan it in the next PI, or abandon and recreate the session
Read-only — this is another team's board.You are not a member of that teamSwitch to your team in the strip
Read-only — the boards open when planning starts.The session is in Briefing or ReviewWait for Start planning (or an adjustment round)
A person cannot be picked as assignee on the boardThey are not a project memberAdd them to the project