Short answer: To manage over-allocation across government programs, convert every person’s program commitments into a percentage of their available hours for the sprint, total them, and rebalance anything above 100% before the sprint is committed. Do it per sprint, not per fiscal year, because days-off and detail assignments change the real number every cycle.

When agencies lose headcount but keep the mission, the same analyst, engineer, or tester ends up “supporting” three programs at once. Each program manager sees a reasonable 40% ask. Nobody sees the 120% total. The overrun surfaces later as a missed demo, a slipped milestone, or a quiet weekend of unpaid catch-up.

Why does over-allocation hide so easily in government programs?

Staffing is usually negotiated program by program. A shared-services developer is promised to a benefits portal, a data migration, and a reporting refresh by three different leads, often in three different meetings. Allocation lives in each lead’s head or in separate spreadsheets, so no single view adds the commitments together.

Public-sector rules make it worse. Detailees, part-time contractors, and staff on training or leave schedules mean headcount is not capacity. A roster of ten can be six effective people in a holiday sprint.

How do you manage allocation and over-allocation step by step?

1. Build one allocation list per person. For every team member, list every program or backlog they touch, with a percentage for the coming sprint. Include meetings, support rotations, and detail assignments. If it is not on the list, it is not planned.
2. Subtract days-off first. Convert the sprint length into working days, then remove federal holidays, approved leave, and scheduled training. Allocation percentages apply to the remaining days, not the calendar sprint.
3. Total each person against 100%. Anyone above 100% is over-allocated. Anyone far below may be an unused resource or a sign that work is hidden elsewhere.
4. Resolve conflicts with an owner, not a hope. Decide which program yields, which work moves to a later sprint, or which commitment is reduced. Write down the decision and who made it.
5. Commit to scope that fits the rebalanced capacity. Only then pull stories into the sprint, sized against past velocity rather than optimism.
6. Review after the sprint. Compare planned allocation with what actually happened and carry the correction into the next sprint.

What does over-allocation look like in numbers?

Take one data analyst shared across three programs in a two-week sprint. The sprint has 10 working days, and one is a federal holiday, leaving 9 days or 72 hours.

• Program A (case reporting): 50%, which is 36 hours
• Program B (data migration): 40%, which is 28.8 hours
• Program C (dashboard refresh): 30%, which is 21.6 hours

Total demand is 86.4 hours against 72 available. That is 120% allocation, an overrun of 14.4 hours in a single sprint, before any unplanned work.

The program leads agree to rebalance: Program A stays at 50% (36 hours), Program B drops to 30% (21.6 hours), and Program C drops to 20% (14.4 hours). The total is 72 hours, or 100%. Program C’s dashboard stories move out a sprint, and that trade-off is recorded with the reason. Leadership now sees a deliberate decision instead of a surprise.

Repeat that across a team and the effect compounds. If a five-person team’s average velocity is 40 points at full availability of 50 person-days, a sprint with only 41 person-days available should plan about 33 points (40 × 41 ÷ 50 = 32.8), not 40.

Why does a written allocation record matter to agencies?

Current public-sector buying and oversight conversations increasingly reward teams that can show what happened, who acted, what changed, and what evidence supported a decision. A sprint plan that records who was allocated where, which days-off were subtracted, and why the team committed to N points is a simple, readable decision trail. It is documentation of planning decisions. It is not a compliance program, and it does not replace one.

How does doing this inside Jira make it repeatable?

The practical failure of the spreadsheet method is drift: the allocation sheet, the leave calendar, and the Jira backlog each go stale on their own schedule. As agencies consolidate tooling on Atlassian Cloud, including Atlassian Government Cloud (AGC) for organizations that need it, keeping capacity next to the backlog removes a whole class of reconciliation work.

Sprint planning with Capacity Planning for Jira puts sprint planning and team capacity on one screen inside the Jira backlog. It uses past velocity, days-off, and allocation to show what a team can realistically take on before you commit. Over-allocation becomes visible while there is still time to change the plan. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform; it does not carry certifications of its own.

FAQ

What is over-allocation in sprint planning?

Over-allocation means a person’s combined commitments across programs exceed their available hours in the sprint. A person assigned 50%, 40%, and 30% to three programs is at 120%.

How often should allocation be reviewed?

Every sprint. Holidays, leave, detail changes, and shifting priorities alter real capacity each cycle, so a fiscal-year allocation table goes stale quickly.

Should part-time and detailed staff be included?

Yes. Count only the hours they are actually available to the team, and record their other commitments so the total stays honest.

Try a 30-minute allocation check

Before your next sprint planning, list each shared person, their programs, and their percentages, then total them. Any number over 100% is your first conversation. To see the same check on one screen in your Jira backlog, use the links below.

Try it: Install free on the Atlassian Marketplace · Help docs