An over-allocated government developer — anyone assigned more than 100% of their time across programs — costs an agency far more than the hours on paper. Context-switching erodes 20–40% of their output, every program they touch slips at once, and each sprint is planned against capacity that doesn’t exist.

The FY26 reality across FedCiv, DoD, and State & Local is fewer people carrying the same mission. When a program loses billets or a contract is descoped, the work rarely shrinks with it — it gets redistributed. The most capable developers absorb the most, and quietly end up committed to 110%, 130%, sometimes 150% of a work week across two or three programs. Nobody decided that. It accumulated, one “can you also cover…” at a time.

What does over-allocation actually cost?

The visible cost is a tired developer. The invisible costs are larger:

• The context-switching tax. Research on multitasking consistently shows that splitting a person across two or more substantial workstreams burns a meaningful share of their time — commonly estimated at 20% or more per additional stream — on re-orientation, duplicate meetings, and rebuilding mental state. A developer split three ways delivers far less than three thirds.
• Correlated slips. When a dedicated developer falls behind, one program slips. When an over-allocated developer falls behind, every program they touch slips in the same sprint — and each program manager reports the slip up a separate chain.
• Queues and wait states. Over-allocated people become bottlenecks. Code reviews sit, questions wait, and teammates who are nominally at full capacity idle behind them.
• Polluted planning data. Velocity from sprints where a developer was silently double-booked understates what the team can really do. Future forecasts inherit the distortion.
• Attrition you can’t afford. Burning out a cleared, domain-experienced developer in the current hiring environment can mean a six-to-twelve-month gap before a replacement is productive.

Why is over-allocation so common in government?

Public-sector structures make it easy to over-commit a person without anyone noticing. Matrixed organizations assign people to programs by percentage. Detail assignments and collateral duties are handed out separately from sprint planning. Contract structures may bill one person across several task orders. And the planning artifacts — usually spreadsheets, one per program — each show only that program’s slice. No single view sums a person’s total commitment, so 60% here plus 40% there plus 10% of ops support never appears anywhere as 110%.

How do you find and fix over-allocation?

1. Sum each person’s allocation across all programs. One row per person, one total. This is a 30-minute exercise and it almost always surprises someone. Anything over 100% is a finding; anything over 85–90% deserves a look.
2. Cap plannable capacity below 100%. Standups, agency all-hands, mandatory training, and help-a-colleague time are real. Most teams do well planning against roughly 80% of nominal availability.
3. Convert allocation into sprint capacity before committing. Working days in the sprint, minus federal holidays and leave, times the person’s allocation to this team, times a focus factor. Commit to that number — not to the roster headcount.
4. Rebalance or resequence, and write the decision down. If someone totals 120%, either an allocation drops or a deliverable moves. Making that trade-off explicit — who was allocated where, what was deferred, and why — gives leadership a defensible record instead of a surprise slip.
5. Recheck every sprint. Allocations drift as programs spin up and down. A number that was true at the start of the quarter is folklore by sprint four.

A worked example

Maria is a senior developer allocated 60% to Program A, 40% to Program B, and expected to give 10% to O&M support — 110% total. The next sprint has 10 working days, minus one federal holiday and one day of leave: 8 days on the job.

• Program A plans on 60% × 8 = 4.8 days of Maria.
• Program B plans on 40% × 8 = 3.2 days.
• O&M assumes 10% × 8 = 0.8 days.
• Total claimed: 8.8 days — against 8 that exist.

Apply a conservative 20% switching penalty for working three streams and Maria’s real productive capacity is about 6.4 days. The gap between what was promised (8.8) and what is deliverable (6.4) is 2.4 days per sprint. Over a six-sprint quarter, that is roughly 14 days — nearly three weeks of committed work that was never going to happen, discovered one missed sprint at a time, across two programs simultaneously.

Why do this in one tool inside Jira?

The math above is simple; keeping it current across programs in separate spreadsheets is what fails — and reconciling copies is exactly the kind of overhead agencies are shedding as they modernize onto Atlassian Cloud. Sprint Planning with Capacity Planning for Jira puts each person’s allocation, days off, and past velocity on one screen inside the Jira backlog, so the team sees real capacity — after holidays, leave, and cross-program allocation — before committing. It also leaves a record of each sprint’s capacity decision: who was allocated at what percentage, which days off were subtracted, and why the team committed to N points — useful when leadership asks how a commitment was reached. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.

FAQ

What allocation percentage is realistic for a government developer?
Plan against roughly 80% of nominal time for a person’s combined assignments. The remainder is consumed by standups, mandatory training, agency events, and unplanned support — whether you budget for it or not.

How do I raise over-allocation with leadership without it sounding like complaining?
Bring the arithmetic, not the adjectives: the person’s summed allocation, the sprint’s real working days, and the gap in days per sprint. A documented 2.4-day-per-sprint shortfall is a resourcing decision for leadership to make; “we’re stretched thin” is not.

Is over-allocation ever acceptable?
As a short, deliberate burst with an end date and a written decision — occasionally. As a steady state, it silently converts your best people into your biggest schedule risk.

Try this week: run the 30-minute allocation audit from step 1 — list every developer, sum their percentages across all programs, and flag anyone over 100% before your next sprint planning.

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