Managing allocation across government programs means tracking every claim on a person’s time in one place, converting those claims into real available hours after days off and overhead, and committing sprint work only to the hours that remain. Over-allocation — counting the same person at or near full capacity on two or more programs at once — is the most common reason multi-program agencies quietly miss their delivery dates.

In most agencies the scarcest resource isn’t a budget line. It’s the senior engineer who is “half on the modernization program, half on sustainment” and also the subject-matter expert everyone pulls into security reviews. On paper she is fully allocated. In practice she is well past 100%, and the overflow doesn’t vanish — it resurfaces as slipped sprints on every program she touches. With hiring freezes and workforce reductions leaving fewer people to carry the same mission, knowing each person’s true remaining capacity before you commit matters more than it ever has.

Why is over-allocation a government-specific problem?

Public-sector delivery is matrixed by design. Engineers are detailed across contracts, shared between a prime and its subs, and pulled into accreditation, audit, and stakeholder meetings that never show up on a task board. A program manager sees only her slice — the 50% she was promised — and plans a full sprint against it. The next program manager does exactly the same with his 50%. Neither is wrong on paper, but the person in the middle now owes 100% of a sprint to two teams simultaneously, before a single hour is spent on standups, reviews, or a mid-sprint tasking from leadership.

The result is a predictable pattern: every program reports “green” at planning and “yellow” at review, because the commitments were never physically possible. In a fixed-deadline, fixed-budget environment, that gap erodes the one thing agencies are trying to build with agile — credible, defensible forecasts they can report up the chain.

The downstream damage goes well beyond a slipped sprint — rework, burnout, and attrition compound quietly. We break down the numbers in the real cost of an over-allocated government developer.

How do you calculate real allocation across programs?

The fix is not a bigger spreadsheet. It’s a disciplined sequence you run every sprint:

1. Inventory every claim on each person. Build the picture per person, not per program. List all programs, standing duties, and committees that draw on their time. If you can’t see all the claims in one place, you can’t see the over-allocation.
2. Convert percentages into real hours. A “60% allocation” is meaningless until you subtract holidays, PTO, training, and ceremony/overhead time. Start from working days in the sprint, remove days off, then apply a focus factor for meetings and coordination.
3. Set an allocation ceiling below 100%. No one delivers eight billable project hours out of every eight-hour day. A ceiling of 75–80% of net hours leaves room for the unplanned taskings that are guaranteed in government work.
4. Reconcile at the sprint boundary. Sum the demand each program wants from a person and compare it to their available hours. Anyone whose demand exceeds their ceiling is over-allocated — flag them before commitment, not at the retro.
5. Force the trade-off into the open. Over-allocation is a decision, not a math error. Someone has to descope, resequence, or release hours. Make that choice explicit and record who decided and why.

A worked example: one developer, two programs

Marcus is a backend developer split “60/60” across Program A (modernization) and Program B (sustainment). That’s 120% on paper — already 20 points over before anyone looks at the calendar.

Now use real hours. The sprint is two weeks — ten working days. Marcus has one PTO day, and one federal holiday falls inside the sprint, leaving eight working days, or 64 gross hours. Apply a 0.75 focus factor for standups, planning, reviews, email, and a standing security-review meeting: 64 × 0.75 = 48 real project hours.

Against those 48 hours, Program A’s backlog wants 34 hours of Marcus’s time and Program B wants 30 — 64 hours of demand for 48 hours of supply. He is over-allocated by 16 hours, a third more than he can deliver. No amount of encouragement closes that gap. The honest move is to descope 16 hours from one program at planning, so both programs commit to something real and report a forecast that holds.

Making allocation repeatable inside Jira

Run that reconciliation by hand and it works once, for one sprint, until the spreadsheet drifts. The point of doing it inside your backlog is repeatability. Sprint planning with Capacity Planning for Jira puts past velocity, days-off, and per-person allocation on one screen, so you see each person’s real remaining hours — and a clear over-allocation flag — before you commit, not after the sprint has already failed.

Doing it in the tool also produces a quiet by-product that public-sector teams increasingly need: a decision trail. Each plan records who was allocated, what days off were subtracted, and why the team committed to the scope it did. That’s not a compliance certification — it’s simply disciplined documentation of your planning decisions, the kind of evidence that helps you answer “why did we commit to this?” months later. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform, so moving this planning off local spreadsheets and into Atlassian Cloud — or Atlassian Government Cloud (AGC) — fits the same modernization path agencies are already on.

FAQ

What’s the difference between allocation and capacity?
Capacity is how many hours a person actually has available in a sprint after days off and overhead. Allocation is how those hours are promised across programs. Over-allocation is when the promises exceed the capacity.

What allocation ceiling should a government team use?
Most teams start at 75–80% of net available hours and adjust from their own history. The unplanned meetings, taskings, and support requests common in agencies make a 100% ceiling a guaranteed miss.

How do we handle a shared SME pulled across many programs?
Treat the SME as a named, capacity-limited resource, not an infinite one. Allocate a fixed number of their hours per sprint, reconcile demand against that number, and make competing programs negotiate the remainder openly.

Try it

Try it: Install free · Help docs

A practical next step: before your next planning session, list every person who sits on two or more programs and calculate their real available hours for the upcoming sprint. If demand beats supply for even one of them, you’ve found a slip before it happens.