Program board, dependencies and risks
What this page is — The two whole-programme views of a PI session: the Program board (every team's plan side by side, with the cross-team dependencies between them) and the Risks tab (the ROAM board of team and programme risks). What it is for — Seeing whether the teams' plans fit together — no team over capacity, no task waiting for another team's work that comes too late — and agreeing, in the room, what could still stop the plan and who owns it. The problem it solves — Each team can produce a perfectly sensible plan that fails the moment it meets the others: Mobile plans checkout for Iteration 1 while the refund API it needs lands in Iteration 2. The Program board makes those collisions visible as red lines, dependencies become explicit agreements between teams, and risks stop living in someone's notebook.
Route: /org/tasks/pi-planning?project=<project>&session=<session>&tab=program · …&tab=risks
Permissions: Take part in a PI session as a team member (propose links for your team's work, raise and edit your team's risks) · the lead or scrum master of the team that owns the needed work, or the facilitator (answer a link) · Run a PI session or the named facilitator (decide conflicts, combine risks, edit any risk) · Open PI Planning sessions read-only (read)
Module: PI Planning · Entry points: the Program board and Risks tabs · the n conflicts button on Team boards · the bell for a dependency request · global search → PI Planning › Program board, › Risks (ROAM) · Cockpit → PI Planning → Open risks
1. Three views of one programme
The Program board merges every team's board on the fly — you never edit it directly. Each task shows under the team that holds it; a task that two teams hold shows under the team that keeps it (the decided winner, else the category's team).
| View | Rows × columns | Answers | You can change |
|---|---|---|---|
| Load | Teams × iterations | "Is any team over capacity in any iteration?" | Nothing — change the team boards |
| Dependencies | Teams × (not planned yet, iterations) | "Does any team wait for work that comes too late?" | Drag a tile to re-plan it on its own team's board (your team, or any for the facilitator) |
| Links | One row per cross-team link | "Who waits for what, by when, and has the other team agreed?" | Accept, decline, remove |
A cross-team dependency always has two sides: the team that waits (it needs) and the team that owns the work waited for (it is needed from). Either side may propose it; the owning team's lead or scrum master — or the facilitator — accepts or declines. Only accepted links become task dependencies when the plan is committed. Links inside one team are drawn on that team's own board, as on the Planning page.
2. Why you would use it
- Over-commitment shows before the demo. A red bar in the Load view means the team planned more hours than its people have in that iteration.
- "Red strings" without string. Out-of-order dependencies are drawn in red, with a suggested fix, so the dependencies sync is spent fixing, not finding.
- Agreements, not assumptions. A proposed link waits for the other team's lead; an accepted one is a commitment that ends up on the tasks.
- Shared specialists are visible. People in two teams show with the hours each team gave them, so a person planned twice is caught.
- Risks are owned. Each risk ends the day as Resolved, Owned, Accepted or Mitigated — the ROAM ritual — and repeated team risks become one programme risk with one owner.
3. The Program board — step by step
| Pip | Control | What it does |
|---|---|---|
| 1 | n tasks are planned by two teams | The facilitator picks the team that keeps each; others see the decision. The merge needs each one decided (the category's team is the default) |
| 2 | Load · Dependencies · Links (n) | Switches the view; Links shows how many links exist |
| 3 | Propose a dependency | Opens the proposal drawer (§4). Team members and the facilitator, while Planning, Review or Adjusting |
| 4 | Shared people | Each person in more than one team, with the hours each team planned on them. Their capacity counts once, their load is every team's work |
| 5 | All teams | Per iteration: tasks, load against the combined capacity, and Goals: — the teams' iteration goals joined |
In each team row, a cell shows the tasks and hours the team planned in that iteration, a bar of load against the team members' capacity, and of n h capacity underneath. The bar turns red when the load is above the project's overload ratio (the Risk radar setting of the project). A team with nobody included shows no capacity. Scroll the table sideways when there are many iterations.
Dependencies view
- Each tile is a task at its planned iteration, in its team's row; Worklist holds linked tasks not planned into an iteration yet.
- A line goes from the work needed to the task that waits. Grey is in order. Red, with a warning icon on the waiting tile, means the needed work ends too late; hover the tile for Waits for … which ends …. A tile waiting for unplanned work is flagged too.
- The fix button on a flagged tile suggests the smallest move that puts the pair in order.
- Drag a tile to another iteration to re-plan it — the move is made on its own team's board. You can drag only your own team's tasks (a toast says Not your team's task — ask them to move it, or propose a dependency); the facilitator can drag any. Dragging works while Planning or Adjusting.
- Declined links are not drawn; proposed ones are.
Links view
| Pip | Column or button | Meaning |
|---|---|---|
| 1 | Needs | The waiting team, its task (click to open it) and the note |
| 2 | From | The team that owns the needed work and that task |
| — | Needed by | The iteration the waiting team needs it by, or — |
| — | Status | Waiting for an answer, Accepted or Declined, and who proposed it |
| 3 | Accept (✓) | "Your team will deliver it in time." The owning team's lead or scrum master, or the facilitator |
| 4 | Decline (✗) | "Your team cannot commit to it." Same people. A declined link can be accepted later, and the other way round |
| — | Remove the link (bin) | Whoever proposed it, or the facilitator |
The owning team's leads and scrum masters get a bell when a link is proposed to them.
4. Propose a cross-team dependency — field reference
| Field | Control | Required | Notes |
|---|---|---|---|
| This task (waits) | Searchable select, grouped by team | Yes | Every task on a team board of the session |
| Needs this task (from another team) | Same list | Yes | Must be on another team's board |
| Kind | Select | Yes (default Finish to start) | Finish to start — B starts after A finishes; Start to start; Finish to finish; Start to finish |
| Lag (days) | Number | No | −365 to 365 |
| Needed by | Select | No | No date — just the order, or one of the PI's iterations |
| Note | Text | No | Up to 500 characters: why it is needed |
The footer reads back the link (Mobile waits for Payments) or what is missing: Pick both tasks., Pick two different tasks., Both tasks are on the same team's board — link them on that board's Dependencies view instead. A team member can propose only links that involve their own team; the same link twice is refused (That link already exists.).
5. The Risks tab (ROAM)
| Pip | Control | What it does |
|---|---|---|
| 1 | Raise a risk | Opens the risk drawer. Team members and the facilitator, while Planning, Review or Adjusting |
| 2 | Combine n into a programme risk | Appears for the facilitator when two or more risks are ticked |
| 3 | Programme risk card | Programme chip; Combined when it was made from team risks; owner |
| 4 | Team risk card | Team, Part of a programme risk when combined, Impact and Likely chips, owner |
The five columns are the ROAM states, each with its count; hover a column title for its meaning. The filter above shows All risks, Programme level only, or one team. Each card carries Edit (pencil — change it or its ROAM state) and Delete (bin, asks first). You can edit your own team's risks; the facilitator edits any, including programme risks and moving a risk between teams. Delete is for the author or the facilitator.
| ROAM state | Means |
|---|---|
| Open | Raised, nobody has taken it yet |
| Owned | Someone owns it and will act on it during the PI |
| Mitigated | A plan reduces its impact or likelihood |
| Accepted | Understood and accepted; nothing more will be done |
| Resolved | No longer a risk — dealt with during planning |
Raise a risk — field reference
| Field | Control | Required | Notes |
|---|---|---|---|
| Title | Text | Yes | Up to 200 characters |
| What could happen | Multi-line text | No | |
| ROAM | Five chips | Yes (default Open) | |
| Belongs to | Select | Yes | Programme level or one of your teams (the facilitator sees every team). Pre-set to your first team |
| Owner | Searchable select | No | The project's members, or Nobody yet |
| Impact, Likelihood | Selects | No | Not set, Low, Medium, High |
Combining risks: the facilitator ticks two or more risks, presses Combine n into a programme risk, checks the title (pre-filled from the first risk), the description (a bullet per original), the ROAM state (default Owned) and the owner, and presses Combine. The new programme risk carries the originals' linked tasks; each original stays in its column marked Part of a programme risk, and no longer counts as open on the cockpit.
Risks belong to the session: they do not create tasks. Raise, edit and combine are open while Planning, Review or Adjusting; afterwards the board is read-only.
6. Worked example
In PI 2026.4 the Load view shows Mobile at 140 h of 192 h in Iteration 2 — high but under the line — and Payments comfortably loaded. The shared scrum master shows 40 h for Mobile and 16 h for Payments.
The Mobile lead proposes: This task (waits) — the app's refund service request; Needs this task — Payments' refund collections task; Finish to start, Needed by Iteration 2, note "The app calls the refund API". The Payments lead gets a bell, opens Links and presses Accept. The facilitator also proposes that a Platform gateway task in Iteration 1 waits for Mobile's retry-policy task in Iteration 2; on Dependencies that line is red. It stays Waiting for an answer until the Mobile lead decides — at the sync, Platform drags its tile to Iteration 3 and the line turns grey.
On Risks, Payments raised Payment gateway sandbox access not granted yet and Mobile raised Gateway credentials arrive late. The facilitator ticks both, combines them into Payment gateway vendor is on the critical path, ROAM Owned, owner herself. The cockpit's open-risk count drops by two.
7. The admin contract
- Team leads and scrum masters must be set on the teams (Organization Settings → Planning Teams); they are the people who answer links to their team.
- The overload ratio that turns a Load bar red is the project's Risk radar setting; capacity comes from each person's planning capacity and the project's Planning settings.
- Task dependencies written at commit follow the project's normal dependency rules; a cycle among accepted links is reported as a blocking problem in the commit review.
- Owners must be project members.
8. Don't confuse this with…
- Planning → Dependencies — dependencies within one board. The same matrix is used here with teams as rows, but cross-team links are proposed and accepted first, and only accepted ones are committed.
- Risk radar — risk signals the platform computes from live tasks. ROAM risks here are raised by people during the event.
- Discussion — talk. A risk on this tab has a state and an owner (Live session).
9. Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| "Nothing to show yet" | The session is not published | Publish it |
| No Propose a dependency | You are an observer, or the session is in Briefing, Committed or Closed | Join a team; wait for planning |
| propose links for your own team's work | Neither task is on your team's board | Ask one of the two teams, or the facilitator |
| No ✓ / ✗ on a link | You are not in the owning team, or the session is not Planning, Review or Adjusting | Ask that team's lead |
| No ✓ / ✗ on a link to your team | Only the owning team's lead or scrum master (or the facilitator) sees them | Ask them; set roles in Planning Teams |
| Not your team's task when dragging | The tile belongs to another team | Ask that team, or propose a dependency |
| A dependency is not on the tasks after commit | It was not accepted | Accept it before merging |
| A load bar shows no capacity | None of the team's members is included in that iteration's capacity | Check the team board's capacity |
| No Combine button | Fewer than two risks ticked, or you are not the facilitator | Tick two or more |
| Cannot edit another team's risk | Only the facilitator edits other teams' and programme risks | Ask the facilitator |