/
Capacity Change Tracking & the Committed Release Date: How It Works

Try Advanced Release Planning for Jira Cloud free for 30 days

Capacity Change Tracking & the Committed Release Date: How It Works

This page explains how Release Management, Roadmaps & Product Portfolio for Jira treats a change in team capacity as a live risk to a committed release date — not just a number set once at planning. It is a neutral, factual companion to the article Capacity Risk: The Third Thing That Erodes a Committed Release Date.

A confidence vote at planning is a snapshot. The commitment your team makes is expert judgment — the app does not replace it. It keeps that commitment current as the real team changes week to week.

Two kinds of capacity loss

Not all lost capacity behaves the same way:

  • Planned capacity — vacation, public holidays, a known leave. These are entered up front and folded into the forecast on day one. See Capacity Planning with PTO & Holidays: How It Works.

  • Unplanned capacity change (capacity risk) — an incident that consumes a sprint, a reassignment mid-increment, a resignation, or the ramp-up of a new hire. These land after the commitment, which is exactly what makes them a risk to the date.

Unplanned work: when capacity erodes as work, not people

Capacity can also erode while the team itself is unchanged. Incidents, expedite requests, and escaped defects consume the team's hours without appearing in the release backlog — headcount is stable, but delivered throughput on the release drops.

Because the forecast is built on the team's real delivered throughput, the normal, historical level of interrupt work is already reflected in it. What the forecast surfaces is a change from that level: when unplanned work spikes after the commitment, subsequent throughput data pulls the forecast dates later, and the shift is reported in days against the committed date — the same signal as any other capacity change.

Companion article: Unplanned Work: The Capacity Thief Your Release Plan Never Saw.

How a capacity change re-forecasts the committed date

The forecast is capacity-aware. A Capacity Awareness setting factors real team availability — throughput, work in progress, and time off — into the Monte Carlo simulation. When availability changes, the committed date is re-forecast and the shift is reported in days.

The committed date is always carried with its confidence, across three percentile bands:

  • P50 — the optimistic / stretch end.

  • P85 — the level most teams commit at; the default committable line.

  • P95 — the conservative end.

A release is on-track when its committed date sits on or after the P85 line, and at-risk when a capacity change pushes it before P85.

Reading and acting on the signal

  • Green (at or above P85) — the commitment still holds; no action needed.

  • Amber (between P50 and P85) — the moment to act: restore capacity if you can, trim scope at the MoSCoW cut-line, resequence a dependency, or renegotiate the committed date while slack remains.

  • Red (below P50) — treat as a re-plan.

The goal is to catch capacity erosion in the week it starts — not at the demo — while there is still room to trade.

Related