Configuring Team Velocity and Capacity in Jira Align for Accurate PI Forecasting

Set velocity and capacity once per sprint to get reliable Program Increment forecasts

The most direct way to improve PI planning accuracy in Jira Align is to enter the team’s velocity (story points per sprint) and capacity (available hours per sprint) in the Capacity Planning screen for each upcoming sprint. When these values are correct, Jira Align rolls them up to the program level, compares them against committed story points, and shows over/under‑capacity warnings on the PI Planning board.

Where to enter the values

1. Log in to Jira Align with a role that can edit team data (e.g., Team Admin or Program Admin).
2. Navigate to Teams → [Team Name] → Capacity Planning.
3. For each sprint in the current PI, fill in:
• Velocity – historical average story points the team completes per sprint.
• Capacity – total hours the team can work on development during the sprint.
4. Click Save.

Worked example: calculating capacity and velocity

Consider a Scrum team with five developers.

• Each developer allocates 6 hours per day to development work (the remaining 2 hours are for meetings, email, etc.).
• Sprint length is two weeks = 10 working days.
• Capacity per developer = 6 hrs/day × 10 days = 60 hrs.
• Team capacity = 5 developers × 60 hrs = 300 hours per sprint.

Assume the team’s historical velocity, based on the last three sprints, is 45 story points per sprint.

Velocity = 45 story points
Capacity = 300 hours

Enter these numbers in the Capacity Planning screen for each sprint of the PI. Jira Align will then:

• Sum the capacities of all teams to show total program availability.
• Compare the sum of committed story points (converted to hours using the team’s velocity) against the capacity.
• Display a warning icon if committed work exceeds available capacity.

Limits and constraints

• Values are stored per sprint; editing a sprint’s capacity does not retroactively change already committed work.
• The UI prevents negative numbers and caps capacity at 1,600 hours per sprint (based on an 8‑hour day).
• Velocity and capacity fields are independent; putting velocity in the capacity field (or vice‑versa) breaks the PI commitment calculation.
• Issue‑level estimates (story points, hours) do not override these sprint‑level values; they are only used for roll‑up.

Common mistakes and how to avoid them

1. Confusing units – entering story points in the capacity field makes the program think the team has far more (or fewer) hours than it actually does, leading to false over/under‑capacity alerts. Fix: Keep velocity in story points, capacity in hours.
2. Using calendar days instead of working days – if you multiply by 14 days instead of 10, capacity is inflated by 40 %. Fix: Subtract non‑working time (meetings, time off) before calculating.
3. Forgetting to refresh the PI board – capacity changes only appear after a manual Refresh on the PI Planning board or after the next PI sync. Fix: Click the refresh button after saving.
4. Setting values mid‑PI and expecting immediate rollback – changes affect only future sprints; already committed work stays unchanged. Fix: Plan adjustments for the next PI or use the Adjust Commitment feature if needed.

Verifying the configuration

1. After saving, open the PI Planning board for the upcoming PI.
2. Locate the team’s capacity bar; the tooltip should show the entered hours (e.g., 300 hrs).
3. Check the PI Objectives view: the team’s committed story points should not exceed the capacity‑derived limit; a warning icon appears if they do.
4. Optional API check: run a GET request to retrieve the stored values.

GET https://{your-instance}.jiraalign.com/rest/api/2/teams/{teamId}/capacity
Authorization: Bearer {your-token}

The response JSON will contain velocity and capacityPerSprint fields matching what you entered. If the numbers differ, re‑enter them in the UI and save again.

Practical takeaway

Accurate PI forecasting in Jira Align hinges on entering correct, sprint‑specific velocity (story points) and capacity (hours) for each team. Treat these as baseline planning numbers, verify them on the PI board, and avoid mixing units or assuming mid‑PI changes will roll back committed work.