Capacity planning for a multi-team agile program means rolling up each team’s real, sprint-by-sprint availability — not headcount, and not last year’s org chart — into one program-level number before you commit to a Program Increment, then re-checking that number every sprint as cross-team dependencies shift. Skip that roll-up and the most common failure mode in large-agency scaled agile shows up right on schedule: three teams hit their sprint goals, a fourth one doesn’t, and the dependency between them means the whole program slips anyway.

That failure isn’t a motivation problem or a planning-software problem in the way most agencies assume. It’s a visibility problem. When four, six, or ten teams each track their own capacity in their own spreadsheet, nobody above the team level can see the real number until it’s too late to do anything but explain the miss up the chain.

Why Does Capacity Planning Get Harder With Multiple Teams?

A single scrum team can eyeball its own capacity: last sprint’s velocity, minus a few days of PTO, minus a training day. It’s rough, but it’s survivable at that scale. Scaled programs remove that safety margin in three ways.

First, the math doesn’t add — it compounds. Four teams each quietly overcommitting by 15% doesn’t produce a program that’s 15% behind; it produces a program where the slowest team’s shortfall blocks the other three, because in a real agency architecture, teams depend on each other’s outputs.

Second, allocation is rarely 100% and rarely stable. In most agencies, staff are detailed to audits, incident response, other initiatives, or a hiring freeze leaves a role unbackfilled for a quarter. Contractor task orders ramp up and down independent of the program’s sprint calendar. None of that shows up in a velocity chart until the sprint is already underway.

Third — and this is the one leadership feels first — headcount is under more pressure than it used to be. Flat or shrinking budgets and workforce attrition across FedCiv, DoD, and state agencies mean most programs are running the same mission scope with fewer people than they planned for eighteen months ago. When staff are cut, knowing your teams’ real capacity before you commit matters more, not less — a rough guess that was tolerable at full staffing becomes a broken commitment at reduced staffing.

How Do You Roll Up Capacity Across Teams in a Large Program?

The fix isn’t a bigger spreadsheet. It’s a consistent, per-team capacity number that program leadership can see rolled up before anyone commits. Five steps make that repeatable:

• Capture each team’s capacity separately, not as an average. A four-team program isn’t one team times four — blending the numbers hides the one team that’s actually at risk.
• Base each number on past velocity, confirmed days-off, and current allocation — not nominal headcount. A team of seven at 70% allocation with two people on leave is not a team of seven.
• Flag cross-team dependencies before the commitment is made, not during the retro. If Team B’s sprint goal depends on an API Team A hasn’t started, that’s a capacity risk for Team B whether or not Team B’s own math looks fine.
• Reserve a dependency buffer per team, in addition to any program-level contingency. A single shared buffer gets consumed by whichever team asks first.
• Re-baseline every sprint, not once per Program Increment. Allocation shifts mid-PI more often than plans acknowledge; a capacity number that’s four sprints stale is a guess wearing a spreadsheet.

A Worked Example: Four Teams, One Program Increment

Consider a state health-and-human-services modernization program with four delivery teams — Eligibility, Case Management, Portal, and Data Integration — each nominally sized for 40 story points a sprint based on last quarter’s velocity.

At PI planning, program leadership does the rough math: 40 points × 4 teams = 160 points of program capacity. But when each team lead accounts for actual availability, the real numbers look different: Eligibility comes in at 32 points (one training day, two staff detailed to an incident-response rotation at 50%). Case Management holds at 28. Portal drops to 22 (a contractor task order ramping down, one developer pulled for a security audit). Data Integration falls to 18 (a two-day agency-wide training blackout, plus a senior engineer at 25% allocation to another initiative).

That’s a real program capacity of 100 points against a planned 160 — a 38% gap between what leadership assumed and what the teams can actually deliver. Worse, 6 of Data Integration’s 18 points are the dependency Portal needs to ship its committed feature; if that slips, Portal’s real usable capacity for that dependency-linked work drops further, independent of its own 22-point number. Surfacing that before commitment turns a mid-PI surprise into a pre-PI conversation about scope.

Doing This in One Screen Inside Jira

The reason this kind of roll-up rarely happens in practice isn’t that program leads don’t know it matters — it’s that pulling velocity, days-off, and allocation for six teams out of six spreadsheets before every PI planning session is tedious enough that it quietly stops happening after the first quarter. Sprint Planning with Capacity Planning for Jira keeps that math inside the Jira backlog each team already works in: past velocity, days-off, and allocation per person show up on one screen before a team commits, so a program lead can look at four or six teams’ real numbers side by side instead of reconciling spreadsheets. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001–certified cloud platform, which matters as more agencies consolidate scaled programs onto Atlassian Government Cloud rather than a mix of Data Center instances and offline trackers.

FAQ

How is scaled capacity planning different from single-team sprint planning?
A single team can tolerate a rough capacity estimate because the consequences stay inside that team. In a multi-team program, one team’s overcommitment becomes every dependent team’s blocker, so the numbers need to be visible and current at the program level, not just the team level.

What’s the most common capacity mistake in large-agency programs?
Planning against nominal headcount instead of confirmed availability — treating a seven-person team as seven full-time contributors when detail assignments, training, and partial allocation to other initiatives routinely take 20–30% of that off the table.

How often should a program recalculate its capacity number?
Every sprint, not once per Program Increment. Allocation and staffing shift continuously enough in government programs that a PI-old number is usually already wrong by the third sprint.

Before your next PI planning session, try a quick capacity audit: for each team, write down last sprint’s actual velocity, confirmed days-off for the coming sprint, and current allocation percentage — then compare that rolled-up number to what leadership assumed the program could deliver. The gap is usually bigger than expected.

Try it: Install free · Help docs