# PI Planning Board: [Train name], PI [number]

> A record of a planning interval (PI) planning event for a team of
> agile teams that plan and deliver together: the context and features
> going in, each team's capacity and objectives with business value, the
> board of features, milestones and cross-team dependencies by
> iteration, the risks sorted with the ROAM convention, the confidence
> vote, and, at the end of the interval, the results against plan.
> PI planning is best known from the Scaled Agile Framework (SAFe), where
> it is a recurring, typically two-day event for an Agile Release Train
> every 8 to 12 weeks. This page is a generic, original format and does
> not reproduce SAFe material. Replace every `[bracketed]` value and
> every row marked *Example*.

<!--
Guidance: How to use this template
- Prepare sections 1 and 2 before the event: business context, the top
  features in priority order, and each team's capacity.
- During the event, teams draft their iteration plans and objectives,
  then the board in section 4 makes dependencies visible. Fill section 5
  (risks) live as teams raise them.
- Plan to about 80% of capacity. Put stretch work into uncommitted
  objectives instead of filling every iteration.
- Business owners, not the teams, assign planned business value to
  objectives, after discussing them with each team.
- After the interval, fill section 7 (results) so predictability can be
  measured and the next planning is more realistic.
- Common pitfall: a dependency drawn on the board without an agreed
  date and owner on both sides.
-->

## Document control

<!-- Guidance: One document per planning interval. Keep the event agenda and outputs together. -->

| Field | Value |
|---|---|
| Document ID | [PIP-TRAIN-PI] |
| Train | [Train name] |
| Planning interval | [PI number] |
| PI dates | YYYY-MM-DD to YYYY-MM-DD |
| Iterations | [N development iterations of N weeks, plus an innovation and planning iteration if used] |
| Planning event | YYYY-MM-DD to YYYY-MM-DD, [location or online] |
| Facilitator | [@train-facilitator] |
| Business owners | [@name, @name] |
| Version | [1.0] |
| Status | [Draft / Committed / Closed with results] |
| Classification | [Internal] |

### Approvals

| Role | Name | Action | Date |
|---|---|---|---|
| Train facilitator | [@facilitator] | Publish plan | YYYY-MM-DD |
| Business owner | [@business-owner] | Agree objectives and business value | YYYY-MM-DD |
| Product management | [@product-manager] | Confirm feature priorities | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | Pre-planning inputs |
| 1.0 | YYYY-MM-DD | [@author] | Committed plan after confidence vote |
| 1.1 | YYYY-MM-DD | [@author] | Results added at end of interval |

The worked example is the **Claims Digital** train of the fictional
**Fernhallow Insurance Group**: four teams (Atlas, Beacon, Cobalt, Delta)
planning PI 27.2, from 2027-04-05 to 2027-06-11: four two-week
iterations and a two-week innovation and planning iteration.

| Iteration | Dates |
|---|---|
| I1 | 2027-04-05 to 2027-04-16 |
| I2 | 2027-04-19 to 2027-04-30 |
| I3 | 2027-05-03 to 2027-05-14 |
| I4 | 2027-05-17 to 2027-05-28 |
| IP (innovation and planning) | 2027-05-31 to 2027-06-11 |

## 1. Context and features

<!-- Guidance: The business context and the top features in priority order, as presented at the start of the event. Keep the list to what the train can realistically consider. -->

| Rank | Feature ID | Feature | Benefit hypothesis | Owner |
|---|---|---|---|---|
| [N] | [FEAT-NNN] | [Feature] | [Expected outcome] | [@product-manager] |
| 1 *(Example)* | FEAT-201 | Online first notice of loss for motor claims | 30% of new motor claims start online | [@product-manager] |
| 2 *(Example)* | FEAT-202 | Photo upload for damage evidence | Assessor visits fall for minor damage | [@product-manager] |
| 3 *(Example)* | FEAT-203 | Claim status tracker | Status calls to the contact centre fall | [@product-manager] |
| 4 *(Example)* | FEAT-204 | Fraud signal hand-off to the investigations team | Faster referral of suspicious claims | [@product-manager] |

Milestones and fixed dates: [regulatory dates, releases, events].

*Example:* Marketing campaign for online claims starts 2027-06-01.

## 2. Team capacity

<!-- Guidance: Capacity for the interval, in each team's own units (story points from velocity history or hours), minus leave and holidays. Load is the planned work. Do not compare points across teams. -->

| Team | Members | Velocity per iteration | Capacity for 4 iterations after leave | Planned load | Load % |
|---|---|---|---|---|---|
| [Team] | [N] | [Points] | [Points] | [Points] | [%] |
| Atlas *(Example)* | 6 | 40 | 152 (160 minus 8) | 122 | 80.3% |
| Beacon *(Example)* | 5 | 34 | 130 (136 minus 6) | 104 | 80.0% |
| Cobalt *(Example)* | 7 | 46 | 174 (184 minus 10) | 140 | 80.5% |
| Delta *(Example)* | 5 | 32 | 124 (128 minus 4) | 100 | 80.6% |
| **Train** *(Example)* | **23** | | **580** | **466** | **80.3%** |

## 3. Team objectives

<!-- Guidance: Each team writes short objectives in business terms, marks each committed or uncommitted, and business owners assign planned business value (a 1 to 10 scale is common). Repeat the table for each team. -->

### 3.1 Team [name]

| ID | Objective | Committed? | Planned business value | Features |
|---|---|---|---|---|
| [OBJ-T-N] | [Objective] | [Committed / Uncommitted] | [1 to 10] | [FEAT-NNN] |
| OBJ-A1 *(Example)* | Policyholders can report a motor claim online, end to end | Committed | 10 | FEAT-201 |
| OBJ-A2 *(Example)* | Policyholders can upload damage photos, scanned for malware | Committed | 8 | FEAT-202 |
| OBJ-A3 *(Example)* | Claim reference sent by email and text within 1 minute | Committed | 7 | FEAT-201 |
| OBJ-A4 *(Example)* | Photo quality hints on mobile | Uncommitted | 5 | FEAT-202 |

*Example:* Team Atlas planned business value for committed objectives is
25 (10 + 8 + 7).

## 4. Train board

<!-- Guidance: Features and milestones by team and iteration, with dependencies. A table works in Markdown; draw the dependency arrows in the diagram below. Every dependency has an owner on both sides and a needed-by date. -->

| Team | I1 | I2 | I3 | I4 | IP |
|---|---|---|---|---|---|
| [Team] | [Feature or milestone] | | | | |
| Atlas *(Example)* | FEAT-201 form | FEAT-201 submit | FEAT-202 upload | FEAT-202 scan | Innovation |
| Beacon *(Example)* | Claims API v2 | FEAT-203 events | FEAT-203 tracker | Hardening | Innovation |
| Cobalt *(Example)* | Document store | Malware scan service | FEAT-204 rules | FEAT-204 hand-off | Innovation |
| Delta *(Example)* | Notification service | FEAT-201 messages | FEAT-203 alerts | Load test | Innovation |
| Milestones *(Example)* | | | Online claims beta 2027-05-14 | | Campaign 2027-06-01 |

| Dep ID | From team (needs) | To team (provides) | What | Needed by | Status |
|---|---|---|---|---|---|
| [DEP-NN] | [Team] | [Team] | [Item] | [Iteration] | [Agreed / At risk] |
| DEP-01 *(Example)* | Atlas | Beacon | Claims API v2 to submit FNOL | End of I1 | Agreed |
| DEP-02 *(Example)* | Atlas | Cobalt | Malware scan service for photo upload | End of I2 | At risk |
| DEP-03 *(Example)* | Atlas | Delta | Notification service for claim reference | End of I1 | Agreed |

```mermaid
flowchart LR
    B1["Beacon: Claims API v2 (I1)"] -->|DEP-01| A2["Atlas: FEAT-201 submit (I2)"]
    D1["Delta: Notification service (I1)"] -->|DEP-03| A2
    C2["Cobalt: Malware scan service (I2)"] -->|DEP-02| A3["Atlas: FEAT-202 upload (I3)"]
    A2 --> M1["Milestone: online claims beta 2027-05-14"]
```

## 5. Risks (ROAM)

<!-- Guidance: Each train-level risk raised during planning is discussed in the room and sorted: Resolved (no longer a concern), Owned (someone takes it), Accepted (nothing more can be done, the train accepts it), Mitigated (a plan reduces it). Record owner and date. -->

| ID | Risk | ROAM | Owner | Action | Review date |
|---|---|---|---|---|---|
| [RSK-NN] | [Risk] | [Resolved / Owned / Accepted / Mitigated] | [@owner] | [Action] | YYYY-MM-DD |
| RSK-01 *(Example)* | Malware scan vendor contract not signed before I2 | Owned | [@cobalt-lead] | Escalate to procurement, fallback to open-source scanner | 2027-04-16 |
| RSK-02 *(Example)* | Two Delta members on leave in I3 | Accepted | [@delta-lead] | Capacity already reduced | n/a |
| RSK-03 *(Example)* | Claims API performance under campaign load | Mitigated | [@beacon-lead] | Load test in I4 | 2027-05-28 |
| RSK-04 *(Example)* | Unclear data retention for photos | Resolved | [@privacy-lead] | Retention rule confirmed during planning | Done |

## 6. Confidence vote and commitment

<!-- Guidance: After the final plans, everyone votes on confidence in the plan, often with a fist of five (1 low to 5 high). Low votes are discussed and may lead to re-planning. Record the result. -->

| Team | Votes (1 to 5) | Average | Concerns raised |
|---|---|---|---|
| [Team] | [Votes] | [Average] | [Concerns] |
| *Example:* Train | 23 votes: 3 at 5, 15 at 4, 5 at 3 | 3.9 | DEP-02 timing |

Commitment statement: [The teams commit to the committed objectives in
section 3 under the stated risks and dependencies.]

## 7. Results at the end of the interval

<!-- Guidance: Business owners score actual business value for each objective, committed and uncommitted. A common measure of predictability divides actual business value (all objectives) by planned business value (committed only). A range of about 80 to 100% is often treated as predictable; check your own framework's guidance. -->

| Team | Planned BV (committed) | Actual BV | Predictability |
|---|---|---|---|
| [Team] | [N] | [N] | [%] |
| Atlas *(Example)* | 25 | 23 | 92.0% |
| Beacon *(Example)* | 24 | 21 | 87.5% |
| Cobalt *(Example)* | 27 | 28 | 103.7% |
| Delta *(Example)* | 20 | 15 | 75.0% |
| **Train** *(Example)* | **96** | **87** | **90.6%** |

*Example:* Atlas scored 10 on OBJ-A1, 6 on OBJ-A2 (scan service late,
DEP-02), 7 on OBJ-A3 and 0 on OBJ-A4. Cobalt exceeded plan because it
completed an uncommitted objective. Delta's shortfall goes to the train
retrospective.

## 8. Related templates

<!-- Guidance: Link the documents used before and after planning. -->

- [Release plan](../product/release-plan.md) and [Roadmap](../product/roadmap.md)
- [Prioritization (WSJF and others)](../product/prioritization.md)
- [Sprint planning](../product/sprint-planning.md) for each iteration
- [Sprint retrospective](../product/sprint-retro.md)
- [RAID log](./raid-log.md) for risks that outlive the interval
- [Team charter](./team-charter.md)

## Glossary

- **Planning interval (PI):** a fixed timebox of several iterations in which a team of teams plans and delivers together. SAFe 6.0 uses this name; earlier SAFe versions called it a program increment.
- **Train:** a long-lived team of agile teams that plans, commits and delivers together; in SAFe, an Agile Release Train (ART).
- **Innovation and planning (IP) iteration:** a final iteration in the interval kept for innovation, learning and the next planning event.
- **Business value (BV):** a relative score that business owners give an objective.
- **ROAM:** a convention for sorting risks as Resolved, Owned, Accepted or Mitigated.
- **FNOL:** first notice of loss, the first report of an insurance claim.

## Standard and licence note

Structure aligned with PI planning as described in the Scaled Agile
Framework (SAFe 6.0, Scaled Agile, Inc.), PI planning article updated
15 March 2026: https://framework.scaledagile.com/pi-planning. SAFe is
cited by name only: no SAFe text, figures or graphics are reproduced,
and the sections, wording, ROAM and predictability descriptions and the
fictional Fernhallow example are original. Official text: Scaled Agile,
Inc., licensed access and permissions:
https://framework.scaledagile.com/usage-and-permissions. Scaled Agile
Framework and SAFe are registered trademarks of Scaled Agile, Inc.
Check the current SAFe guidance before use. Template licence: MIT.