Over-allocation happens when the shares of a person’s time promised to different programs add up to more than 100%. You manage it with a single allocation map every program manager can see, a hard 100% cap per person, and sprint commitments scaled to allocation-adjusted capacity — recalculated at every sprint boundary.

Picture a state transportation agency after a year of attrition and a hiring freeze: 14 engineers now support three programs that 19 used to. No staffing plan was rewritten. Each program still lists the same names, and each program manager plans sprints as if those names were theirs alone. Add up one data analyst’s assignments — 40% on the traveler-information modernization, 40% on the grants system, 50% on a legacy interface retirement — and she owes 130% of herself every two weeks. Nobody decided that. It accumulated, one reasonable request at a time. Fewer people carrying the same mission makes this arithmetic the rule, not the exception.

Why do government programs over-allocate people?

Over-allocation is rarely one bad decision. Agencies staff in a matrix: a developer belongs to a home office, is funded by two program budgets, and is borrowed for a security review because she is the only one who knows the legacy interface. Each claim is approved by a different manager against a different document. There is no moment when anyone sees the whole person — only slices.

The cost lands unevenly. When someone owes 130% of themselves, the missing 30% comes out of whichever program shouts least — often the long-horizon modernization work the agency cares about most. Sprint after sprint, that program reports slippage no one can quite explain, because the cause sits inside two other programs’ plans. In a fixed-budget, fiscal-year-deadline environment, unexplained slippage is exactly what gets agile programs labeled unpredictable.

How do you manage allocation across government programs?

Five steps, run as a standing routine rather than a one-time cleanup:

1. Build one allocation map and give it an owner. One row per person, one column per program or standing duty, percentages in the cells. The map lives where every program manager can see it, and one named person — a PMO lead or portfolio manager — owns its accuracy. Allocation data scattered across five separate staffing plans is how over-allocation hides.
2. Make 100% a hard cap, and name the tie-breaker. When a row sums past 100%, that is a portfolio decision, not a formatting problem. Decide in advance who arbitrates — usually the portfolio owner — and record what was reduced and why. The cap turns invisible overload into a visible trade-off.
3. Convert allocation into sprint capacity. A percentage is not a plan. For each person: working days in the sprint, minus their days off (leave, holidays, training, details), times their allocation to your program. That product — allocation-adjusted person-days — is the only number sprint planning should trust.
4. Scale the commitment, not the enthusiasm. Compare this sprint’s adjusted person-days to the baseline behind your recent velocity. If the team delivered 40 points with 50 person-days available, it will not deliver 40 with 30. Commit to the proportional number and put the rest below the line.
5. Re-check at every sprint boundary — and write down what changed. Allocations drift: a detail lands, an audit response spins up, a vacancy stays open. Reconcile the map before each planning session and log the changes. Over time that log becomes a record of who was allocated where, what was subtracted, and why each commitment was the size it was — the kind of documentation that answers questions long after the sprint ends.

A worked example: allocation-adjusted capacity for one team

Consider the five people assigned to that traveler-information modernization, planning a ten-working-day sprint:

• Amara — 100% allocated; one mandatory training day → 9 person-days
• Ben — 50% allocated (shared with the grants system) → 5
• Chen — 75% allocated; two days of leave → 6
• Dara — 100% allocated; three days onboarding a new contractor → 7
• Eli — 25% allocated (detailed to an audit response through month-end) → 2.5

The roster says five people, fifty person-days. The map says 29.5 — barely more than half. The team’s last three sprints averaged 40 points on roughly 50 available person-days, about 0.8 points per person-day. An honest commitment for this sprint is 29.5 × 0.8 ≈ 23 points, not 40. Committing to 23 and delivering 24 reads as control; committing to 40 and delivering 24 reads as failure — identical output, opposite conclusions.

Why one screen inside Jira beats the allocation spreadsheet

None of this is hard math. What is hard is doing it every two weeks, for every team, without the spreadsheet quietly rotting — a stale leave tab here, a forgotten detail there. Teams abandon the routine not because it fails but because it costs an hour of collation per sprint.

That collation step is what Sprint planning with Capacity Planning for Jira removes. Past velocity, days off, and per-person allocation sit on one screen inside the Jira backlog, so the allocation-adjusted number is simply there when the team commits — and each plan preserves what was assumed: who was allocated at what share, which days were subtracted, why the commitment was the size it was. For agencies consolidating planning into Atlassian Cloud or Atlassian Government Cloud (AGC) as part of a broader modernization, it replaces the last spreadsheet in the loop. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

How often should program allocations be reviewed?
At minimum at every sprint boundary, since the map feeds planning. Also re-check on trigger events: a new detail or tasker, a departure or long vacancy, an audit or incident response, and the start of a fiscal year, when funding lines and contract assignments reset.

What if two programs both need the same person at the same time?
Escalate to the named tie-breaker rather than letting the person quietly absorb both demands. The portfolio owner decides which program gets the hours this sprint, the other replans, and the decision is recorded. An open, recorded “no” costs far less than a silent double-booking discovered at sprint review.

Does allocation planning work with story points?
Yes. Points measure the team’s throughput; allocation determines how much of the team actually shows up. Scale the point commitment by the ratio of this sprint’s allocation-adjusted person-days to the person-days behind your velocity baseline, as in the example above.

A practical next step: this week, ask every program manager who shares staff with you what percentage of each shared person they believe they have, and add the answers per person. Rows that sum past 100% are commitments you were going to miss — now they are trade-offs you can make on purpose.

Try it: Install Sprint planning with Capacity Planning for Jira free from the Atlassian Marketplace · Help docs