Using Jira Align Capacity Planning to Prevent ART Overcommitment

Problem: Overcommitment during PI planning

When Agile Release Trains (ARTs) enter Program Increment (PI) planning, teams often pull in more story points than they can realistically deliver. The result is missed objectives, uneven load across teams, and a scramble to re‑plan work mid‑PI. Jira Align’s capacity planning view is designed to surface this mismatch before commitments are finalized.

How the capacity view works

Jira Align aggregates three data points for each team in the ART:

1. Historical velocity – the average completed story points per sprint, imported from Jira or entered manually.
2. Planned work – the sum of story points assigned to the team for the upcoming PI.
3. Non‑work time – scheduled time off, holidays, or other capacity‑reducing events.

The tool calculates available capacity as:

available capacity = (team velocity × number of sprints) – planned time off

If the planned work exceeds available capacity, the capacity bar turns red, signaling over‑allocation.

Worked example: A 5‑team ART

Consider an ART with five teams, each with a stable velocity of 30 points per sprint. The PI consists of two sprints, and each team has scheduled two days of time off (≈0.25 sprint per team).

• Velocity per team: 30 points/sprint
• Number of sprints: 2
• Planned time off per team: 0.25 sprint × 30 points = 7.5 points
• Available capacity per team: (30 × 2) – 7.5 = 52.5 points
• Total ART capacity: 5 × 52.5 = 262.5 points

During PI planning the teams collectively commit to 300 points of work. The capacity view shows:

• Total planned work: 300 points
• Total available capacity: 262.5 points
• Excess: 37.5 points (≈1.25 sprints)
• The capacity bar for the ART appears red, highlighting the over‑allocation.

The ART decides to move two low‑priority stories (each estimated at 15 points) to the next PI, reducing planned work to 270 points. The excess drops to 7.5 points, which is within the margin of error, and the bar returns to green.

Trade‑offs and limitations

The forecast relies on the assumption that team velocity remains stable. If a team experiences:

• Sudden changes in membership (e.g., new hires or departures)
• Significant scope changes that affect estimating consistency
• Inaccurate or missing time‑off entries

the capacity calculation can become misleading. Moreover, Jira Align does not automatically re‑assign work; the ART must manually adjust backlog items after reviewing the view.

Actionable steps to validate the capacity view

1. Navigate to Plans → Program Increment → Capacity view in Jira Align.
2. Confirm that the capacity bar for each team equals (velocity × sprints) – time off. You can spot‑check by hovering over the bar to see the underlying numbers.
3. Create a test team with a known velocity (e.g., 20 points/sprint) and enter a fixed set of story points (e.g., 80 points for a two‑sprint PI). Observe that the forecast updates correctly when you adjust the velocity field.
4. For programmatic verification, call the REST API:

curl -H "Authorization: Bearer " \
     https://.restdev.atlassian.com/rest/align/1.0/capacity?programIncrementId=

The JSON response includes availableCapacity and plannedWork fields; compare these to the UI values to ensure consistency.

Closing

Jira Align’s capacity planning view gives ARTs a quick, data‑driven way to spot over‑commitment before the PI starts. By grounding the forecast in historical velocity and explicit time‑off, teams can make informed trade‑offs during planning. Remember to keep the underlying data accurate and treat the view as a decision‑aid, not an automatic scheduler.