Every capacity planning template has the same columns. Name. Role. Allocation. Days off this sprint. Available hours. A total at the bottom, and a second total for the release. The spreadsheet one, the Confluence one, the one your PMO exports from the HR system every quarter: the columns barely vary, because the columns are the assumption.

It gets filled in during the week of the confidence vote, by the people who just made the vote, from what they knew about their own team: who was on the release, who was half-time on the platform migration, who was out for two weeks in March. That is expert engineering judgment about availability, and the vote was built on it. The problem is not the judgment. The problem is that the sheet is read as true on every day after the day it was written.

What a capacity planning template actually records

Strip the template to the fields that carry a decision and there are three: who is on the release, how much of each person the release gets, and when they are not there. Everything else on the sheet is arithmetic on those three, collapsed into a number the vote can use: 312 hours a sprint, or 7 FTE. That number is the capacity assumption behind the committed date, and the vote was implicitly a vote on it holding for the length of the release. The template is the assumption made legible. It is also a snapshot.

Why capacity is the quietest of the three

Look at the three things that erode a release date after the vote (scope creep, dependencies surfaced too late, capacity changes) and notice how each one announces itself. Scope growth shows up in the backlog. A late dependency shows up as a blocked ticket. A capacity change shows up nowhere in Jira by default: the senior engineer pulled onto the incident is still the assignee, the new hire is still one FTE, the person who resigned is still on the roster until someone edits it.

So the template says 7. It said 7 in January. It will say 7 in April, when the throughput behind that 7 has been running like 5 for six weeks. The capacity risk post walks through the specific ways that happens; the point here is that the document is the last place the change will ever appear.

There are two kinds of capacity loss, and the template is built for one. Planned loss (vacation, public holidays, a known leave) is in the sheet, because the team knew about it at the vote. Unplanned change (an incident that eats a sprint, a mid-increment reassignment, a resignation, a ramp-up) is not in the sheet and never will be, because it lands after the vote. That is exactly what makes it a risk to the date.

What to write in each field so it stays honest

You do not need a different capacity planning template. You need the same fields filled with references to live things instead of copies of them.

• Roster: list the Jira user accounts assigned to the issues, not names typed into a sheet. Availability then attaches to the people doing the work, and a reassignment is visible where the work is.
• Time off: record PTO per person, per day, against those accounts, and give each team its own public-holiday calendar. A blanket “80% focus factor” is a guess about the whole team; two named people out the same week in March is a fact about the release.
• Allocation: write down the throughput window the forecast was built on (“last 8 sprints, incidents included”) instead of a percentage. The window already contains the allocation the team actually achieved, interrupts and all; “70% allocated” is what someone hoped in planning week.
• The total: put it next to the date and its band, as the assumption it is: “March 31, committed at P85, on this roster with this time off.” Now the sheet says what the vote assumed, so it can be re-read against evidence later.
• One line under the total: “Re-read at every sprint boundary; renegotiate if the committed date drops below P85.” That sentence turns a staffing record into a plan, because it says when the plan is allowed to be wrong.

None of this second-guesses the vote. The team still decides who is on the release, which window the forecast trusts, and what confidence level it commits at. The template just stops pretending those decisions were made once and for all.

The same defect runs one level up. The capacity-per-iteration table is one of five fields on a PI planning template, and it expires faster than any of the other four; the same reference-not-copy fix applies to each of them.

Keeping the capacity field live in Jira

To be precise about what Advanced Release Planning for Jira does and does not do here: it does not ship a capacity planning template, it does not store one, and it is not a resource-management or HR system. The sheet is yours. What the app keeps live is the assumption the sheet was trying to record.

Time off is recorded against real Jira user accounts, so a person’s availability drops only on the days they are away rather than as a percentage smeared across the team. Public holidays are imported in bulk from a CSV and applied per team, and a distributed team can carry several calendars at once (the PTO and holidays post covers the mechanics). With Capacity Awareness on, the Monte Carlo forecast folds throughput, work in progress and that time off into the simulation, and the committed date is carried with its P50, P85 and P95 lines. When availability changes, the date is re-forecast and the shift is reported in days.

The unplanned changes, the ones the template never sees, arrive through the throughput data. The forecast reads what the team actually completed, so the 7 that has been running like 5 is in the forecast whether or not anyone edited the sheet. The committed date drifts toward its P85 line while there is still slack to trade, and the re-read line under your total becomes a two-minute check at each sprint boundary. If the date has slipped into the P50 to P85 band, you renegotiate: restore capacity if you can, move work across the MoSCoW cut-line, resequence a dependency, or re-commit on a new date with its band.

The neutral feature reference is on our docs site: Capacity Change Tracking & the Committed Release Date: How It Works.

Frequently asked questions

What should a capacity planning template include for an agile release?

The roster as Jira user accounts, per-person time off, a public-holiday calendar per team, the throughput window the forecast uses, and the committed date written with its P50/P85/P95 band and the line the team committed at. Those are the fields the confidence vote depended on; keep them, rather than summarising them into a single hours figure.

How often should the capacity plan be updated after the confidence vote?

Re-read it at every sprint or iteration boundary, and update it whenever real availability changes. If the fields reference live Jira data rather than copies of it, the re-read is a look at the forecast: has the committed date stayed on or after its P85 line, or not.

Keep the assumption a live one

Your capacity planning template is not wrong, and neither was the vote that used it. It was right on the day it was written, about a team that has since changed. Point its fields at the real accounts, the real time off and a throughput window, carry the date with its band, and the assumption stays as current as the team it describes, which is what stops the release plan it feeds from going stale.

See how Advanced Release Planning keeps a committed release date 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