Capacity planning for a multi-team agile program works when each team computes its own real capacity — past velocity adjusted for days off and allocation — shared specialists are planned as explicit constraints, and the program commitment is the sum of team commitments rather than a target pushed down from above.

Picture the quarterly planning session for a six-team modernization program: a full day of mapping dependencies, a confident program-level commitment — and by week three, two teams are quietly renegotiating scope because the plan assumed people who were never fully available to them. Nobody lied. The math was just done at the wrong level.

Why does multi-team capacity planning break down in large agencies?

Scaling frameworks assume dedicated, stable teams. Large agencies rarely have them. Staff are matrixed across programs, the security engineer and the accessibility specialist each support four teams, a detail pulls a lead away for a data call, and a hiring freeze means the org chart shows positions that no longer have people in them.

The most common failure is planning the program as one pool: “we have forty people across six teams, so the program can absorb roughly N points a sprint.” Pools hide the fact that work does not move between teams as easily as numbers do. A spare ten percent on the integrations team cannot finish the case-management team’s backlog.

Workforce reductions make this sharper, not softer. When positions go unfilled, a program plan built on last year’s headcount becomes fiction — unless someone redoes the arithmetic team by team. Fewer people and the same mission means the planning discipline matters more, not less.

How do you plan capacity across multiple agile teams?

1. Compute capacity per team, never per program. For each team, start from its own velocity baseline (the average of the last three to five sprints), then adjust for this sprint’s reality: working days after holidays, each member’s days off, and each member’s allocation percentage. A team is the unit that delivers; it is also the unit that has capacity.
2. Plan shared specialists as named constraints. List every person who serves more than one team — security, data, accessibility, contracting support. Give each a per-team allocation and check that the total across teams is at most 100 percent. If the security engineer is 25 percent on three teams, the fourth request is a scheduling decision, not a favor.
3. Roll commitments up; don’t push targets down. The program commitment is the sum of what the teams can commit. If leadership’s target is higher, the gap is visible in week zero — and it becomes a scope, sequencing, or staffing conversation backed by arithmetic, instead of a delivery failure discovered in week six.
4. Re-check at every sprint boundary and write down what changed. A quarterly plan decays: someone retires, a detail lands, a holiday removes days. Re-run the capacity numbers before each sprint and record what changed and why the commitment is what it is. That running record is what lets a PMO answer “why did the forecast move?” with evidence instead of recollection.

A worked example: three teams, one sprint

Consider a state licensing-modernization program with three teams planning a two-week sprint that has nine working days after the Labor Day holiday.

• Portal team: five people, velocity baseline 34 points against a full 50 person-day sprint. Two members are 50 percent allocated to legacy operations, and the team has 4 person-days of leave. Available: (3 × 100% + 2 × 50%) × 9 − 4 = 32 person-days. Commitment: 34 × 32 / 50 ≈ 22 points.
• Case-management team: six people and a 40-point baseline (60 person-days), but one member retired without backfill and another is 75 percent allocated during a data call. Available: 4.75 × 9 − 2 days of leave ≈ 40.75 person-days. Commitment: 40 × 40.75 / 60 ≈ 27 points.
• Integrations team: four people, 25-point baseline (40 person-days), fully dedicated but carrying 5 person-days of leave and training. Available: 31 person-days. Commitment: 25 × 31 / 40 ≈ 19 points.

The roll-up: 22 + 27 + 19 = 68 points. The naive sum of the three velocity baselines is 99. The program is at about two-thirds of its paper capacity this sprint — and everyone knows it before anything is committed, rather than at the retrospective.

How do you make this repeatable inside Jira?

The math above is simple; maintaining it in spreadsheets across three, six, or ten teams every two weeks is where programs give up — the spreadsheet drifts from Jira, and the plan stops being trusted. Doing the same calculation where the backlog lives removes that drift. Sprint Planning with Capacity Planning for Jira puts past velocity, days off, and per-person allocation on one screen in the Jira backlog, so each team sees its real capacity before it commits — and the program roll-up becomes a reading exercise, not a reconciliation project. For agencies consolidating on Atlassian Cloud or Atlassian Government Cloud as part of modernization, it keeps planning in the same platform: the app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. Just as useful for a PMO, each sprint’s plan is a durable record of who was allocated where, what days off were subtracted, and why the team committed to the number it did.

A practical way to start: for one program increment, have each team compute just three numbers per sprint — person-days available, allocation-adjusted person-days, and the resulting commitment — and report the roll-up alongside leadership’s target. One quarter of that data changes the conversation.

FAQ

How is capacity planning different in scaled agile than for a single team?
The per-team math is identical; what changes is that shared people must be planned explicitly and commitments must be aggregated bottom-up. The scaled failure mode is planning the program as one pool of people, which no team actually is.

Should all teams use the same story-point scale so the roll-up is fair?
No. Points are a team-local unit, and forcing a common scale usually distorts estimates. Track each team against its own commitment, and compare teams — if you must — by percentage of commitment delivered, not raw points.

What should happen to the capacity plan after a workforce reduction?
Recompute every affected team’s capacity immediately and re-baseline the program roll-up. The revised numbers are the evidence base for the scope and priority conversation that has to follow; a plan that still assumes the old headcount is the most expensive document in the program.

Try it: Install Sprint Planning with Capacity Planning for Jira free · Help docs

admin

See Full Bio