Visualizing Team Capacity and Dependencies in Jira Align PI Planning

Problem: Hidden Overload and Missed Dependencies

During Program Increment (PI) planning, teams often commit to work without a clear view of each other's load or the links between tasks. When capacity overloads and hidden dependencies surface only after the PI starts, teams miss objectives, scramble to re‑plan, and lose predictability. The core issue is a lack of a shared, real‑time visualisation that surfaces both utilisation percentages and cross‑team dependency arrows before the plan is frozen.

Setting up the PI Planning Board

1. Create the PI – In Jira Align, navigate to Planning → Program Increments, click New PI, and define the start/end dates and number of sprints.
2. Add Teams – Under the PI, select Teams and add the Agile Release Train (ART) members that will participate.
3. Set Capacity per Sprint – For each team, edit the Capacity field for every sprint (e.g., 30 story points per two‑week sprint). Capacity is expressed in the team’s default estimate unit.
4. Import Jira Issues – Ensure the official Application Link between Jira and Jira Align is active, then run Import → Jira Issues to pull in features, stories, and enablers that belong to the PI.
5. Enable Dependency Tracking – In the PI planning board view, toggle Show Dependencies. The board will draw lines between issues that have a Blocks or Is blocked by link in Jira.

Worked Example: Re‑balancing a 5‑Team ART

Consider an ART with five teams (A‑E) planning a two‑sprint PI. After importing Jira issues and setting each team’s capacity to 30 points per sprint, the board displays:

• Team A: 115% load (35 points assigned)
• Team B: 80% load (24 points)
• Team C: 90% load (27 points) with a dependency line to Team B (Story C‑12 blocks Story B‑07)
• Team D: 70% load (21 points)
• Team E: 65% load (20 points)

The planner sees the overload flag on Team A and the dependency risk. Using the board’s what‑if capacity slider, they reduce Team A’s load by moving two story points to Team E (which has spare capacity). After the move:

• Team A: 100% load (30 points)
• Team E: 75% load (23 points)
• All teams now stay ≤100% and the dependency line remains visible, confirming the risk is still tracked but no longer compounded by overload.

This adjustment is performed directly on the board; no Jira edit is required until the plan is committed.

Trade‑offs and Limitations

• Data Freshness – The board reflects only the data that has been synced from Jira. If the Application Link lags or a team forgets to update estimates, the capacity percentages can be misleading. A practical check is to compare the Jira Align issue estimate with the source Jira issue before finalising the PI.
• UI Clutter** – With many teams and numerous dependency lines, the board can become dense, making it hard to follow individual arrows. Using the board’s filter to show only high‑risk dependencies (e.g., those linked to overloaded teams) reduces visual noise.
• Estimate Accuracy – The view assumes that story points (or the chosen estimate unit) are relatively consistent across teams. Large estimation variance can skew the capacity percentages.

Actionable Closing

To keep the PI planning board reliable:

1. Run a weekly PI‑prep sync where the Scrum of Scrums reviews the board, validates estimates, and triggers a manual Jira‑to‑Jira Align sync if needed.
2. Enforce a Definition of Ready that requires an estimate and a link to the parent feature before an issue can be imported.
3. Automate the sync (e.g., via the Jira Align scheduler) to run at least twice per day during the PI planning window.
4. Experiment with the what‑if capacity slider before final commitment; treat the slider as a risk‑mitigation tool, not a final decision.

When the board shows every team at or below 100% capacity and all dependency lines are visible, you have a concrete, actionable baseline for a predictable PI.