Every PI planning template ends the same way. Two days of breakouts, a program board full of string, a ROAM sheet, a capacity table per iteration, and then the last box: the confidence vote. Fist of five, average it, write the number down. If it clears the bar, the plan is committed and the template is filed.

That number is not a guess. It is the considered judgment of the people who will do the work, taken with the full plan in front of them. The problem is not the vote. The problem is that the template records it and then stops. There is no sixth box for what the vote would be on day thirty, when two objectives have grown, a dependency has surfaced that was not on the board, and a senior engineer has been pulled onto an incident. This article walks through the five fields, shows which killer each one is, and describes what to reference in each so the template stays live instead of becoming a photograph.

What a PI planning template actually contains

Strip the branding off any PI planning template, whether it is a Confluence page, a spreadsheet, or a whiteboard tool, and the same five working fields are underneath:

1. PI objectives, split into committed and stretch, with business value scored by the product side.
2. The program board: features by team by iteration, with the cross-team dependencies drawn between them.
3. ROAM risks: every risk named in the room, marked Resolved, Owned, Accepted, or Mitigated.
4. Capacity per iteration: each team’s available points or days for each sprint in the increment, holidays and allocations already subtracted.
5. The confidence vote: the team’s and then the train’s read on whether the objectives will be met.

If you are running the event itself for the first time, our guide to program increment planning in Jira covers the sequence. This article is about what happens to the artifact afterward.

Five fields, three killers, one vote

Read the five fields against why release dates slip after PI planning and the pattern is hard to miss. Four of the fields are not merely related to post-commitment erosion; they are the erosion, written down before it starts.

PI objectives are scope. The committed list is the release boundary the vote was taken against. Scope creep does not arrive as a new objective; it arrives as the third and fourth story that turns out to be inside an objective that was written in one sentence on planning day. Nothing on the template changes when that happens. The objective still reads the same. The line on the committed-versus-stretch split is a confidence decision, and it was made against the objective’s size on day one.

The program board is dependencies. The strings on the board are the dependencies the room could see. The ones that move the date are the ones it could not: the shared component nobody realised two features touched, the vendor interface that turns out to need a firmware release. A dependency that surfaces in iteration four is not on the board, and no one goes back to draw it in.

Capacity per iteration is capacity. This is the most honest field on the template and the one that expires fastest. It records who was available, on planning day, for six iterations ahead. Attrition, incident duty, a reorganisation, an unplanned leave: each one rewrites the number and none of them rewrites the template. The capacity planning template has the same defect in a longer form.

ROAM is all three, with a probability attached. Look at what actually gets written in the risks column of a PI planning template. “Feature X may be larger than estimated” is scope. “Team B’s API may not be ready by iteration 3” is a dependency. “We may lose a contractor at quarter end” is capacity. The ROAM board is the three killers pre-listed by the people best placed to name them, and then marked Owned or Mitigated and left alone.

The confidence vote is the snapshot. It is a genuine reading, taken by the right people, of the four fields above as they stood in that room. What it cannot be is a reading of those fields as they stand now. The fist of five was right on day one; the template simply has nowhere to record whether it is still right.

What each field should reference so it stays live

The fix is not a better template. It is a different kind of entry in each field. A value copied into a document is stale the moment it is copied; a reference to the Jira object the value came from is current every time someone looks. Field by field:

• PI objectives reference the Fix Version (or versions) that hold the committed items. Scope is then whatever is in the version today, not whatever the sentence said. Growth inside an objective shows up as issues added to the version, and the forecast re-runs.
• The program board references Jira issue links between the features, including a placeholder issue for any external or vendor dependency. A dependency that surfaces late is a new link, and a new link is a forecast input, not a note in the margin.
• ROAM risks each reference the object they are a risk to: the Fix Version items for a scope risk, the issue link for a dependency risk, the team’s capacity settings for a capacity risk. Owned or Mitigated then means something you can check, not a status you assigned.
• Capacity per iteration references the roster and time-off settings in the app and the throughput window the team chose. The team still decides which window is representative; that is the assumption they own. The arithmetic runs off the current roster, not the planning-day one.
• The confidence vote is recorded as it was, and paired with the committed date and its live confidence band: the date at 50, 85 and 95 percent, recomputed as the four fields above change. The vote is the team’s judgment on planning day; the band is the same question answered again every day since.

Reading the template on day thirty

Filled in this way, a PI planning template answers a question the ordinary one cannot. Not “what did we commit to?” but “how far has each thing we wrote down moved the date we committed to?” In Advanced Release Planning that reading is attributed: the committed date carries its confidence level, and movement against it is broken out by driver, in days. Objective two grew by four issues: plus six days. The vendor link landed a week late: plus five. The contractor left: plus nine. The vote said 4 out of 5 on planning day; the band says the committed date now sits below 85 percent. That is not a verdict on the vote. It is the vote’s own premises, re-checked, with the arithmetic done at Monte Carlo scale instead of by show of hands.

The point of reading it on day thirty is that day thirty is early enough to do something. Drop a stretch objective back to stretch. Re-sequence the dependency. Borrow capacity. Or re-commit the date, with its band, before the PI boundary chooses for you. Teams that renegotiate from a live reading do it in a working session; teams that renegotiate from a stale template do it in the escalation meeting.

What the app does and does not do here

To be precise about the boundary: Advanced Release Planning does not generate, store, or replace a PI planning template, and it does not model program increments, release trains, or PI objectives as first-class objects. Keep the template wherever your train keeps it. What the app supplies is the reference targets above (Fix Versions, issue links, capacity settings, the throughput window) and the one output no template has: a committed release date with a live 50/85/95 percent confidence band, with every change in scope, dependencies, and capacity attributed to it in days. The neutral how-to for the confidence band is on our docs site: Live Confidence Bands: How They Keep a PI Confidence Vote Current.

Frequently asked questions

Does a live confidence band replace the fist-of-five vote?

No. The vote is the team’s expert judgment on the plan as it stood on planning day, and it stays the reference point. The band answers the same question continuously, from evidence the team validates: the throughput window they chose, the roster they maintain, the scope in the Fix Version. Use the band to decide when a fresh informal vote is worth taking, rather than waiting for the next PI boundary.

Do I need SAFe to use a PI planning template this way?

No. Any quarterly or multi-sprint planning event produces the same five fields under different names: a quarterly objectives list, a dependency map, a risk register, a capacity sheet, and some form of commitment. The reference pattern is the same whatever the template is called.

Keep the vote, keep it current

Your PI planning template already holds the right five things, written by the right people. Give each field a live reference, and read what every one of them is doing to the committed date, in days, before the increment reads it back to you. See how Advanced Release Planning keeps a committed date and its confidence band live in Jira, or install it from the Atlassian Marketplace.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio