Short answer: An over-allocated government developer costs far more than the extra hours imply. A developer split across three work contexts typically loses 20–30% of whatever time remains to context-switching, and — more damaging — their output becomes unpredictable, which destabilizes every sprint commitment that depends on them. The fix is to express each person’s commitments as a percentage of their real, days-off-adjusted capacity before the team commits, not after the sprint misses.

Every agency has one. At a state health agency we’ll call the integrations engineer “the person who knows the eligibility interface.” She is on the modernization team’s board at 100%. She is also the only person who can touch a legacy interface nobody has funded a replacement for, and she is the name that appears whenever an evidence request lands. On paper she is one full-time developer. In practice the team has been planning sprints around a developer who does not exist.

This is not a scheduling annoyance. It is the single most common reason government sprint commitments slip, and it is almost always invisible in the tooling — because Jira shows assignment, not allocation.

Why over-allocation hits public-sector teams harder

Commercial teams over-allocate too. Government teams over-allocate under conditions that make the damage worse:

• Fewer people, same mission. Workforce reductions and hiring freezes don’t reduce the statutory obligations, the reporting cadence, or the fiscal-year milestone. The work is redistributed onto whoever remains — usually the most senior people, who were already the constraint.
• Detailing and collateral duties are normal. A developer detailed 25% to another program is still counted as a full team member on the board. Nobody subtracts anything.
• Fixed deadlines, not fixed scope. Commercial teams can slip a feature. A fiscal-year obligation or a regulatory reporting date does not move, so slack gets absorbed by the individual rather than by the schedule.
• The interrupt work is mandatory. Audit responses, security findings, incident reporting timelines — these outrank sprint work by definition. They aren’t in the backlog, so they aren’t in the plan.

The result is a team that hits 85% of its commitment every sprint and cannot explain why, because on paper the capacity was there.

How do you find and price over-allocation on your team?

1. Build a real capacity baseline per person, not per team

Start with working days in the sprint, subtract holidays, leave, and training, then subtract a fixed overhead percentage for ceremonies, code review, and support rotation. Do this per person. Team-level averages hide exactly the imbalance you’re looking for — a team can look 90% loaded while one person is at 160% and two are at 60%.

2. Count commitments outside your board

Ask each person one question: what else are you obligated to this sprint that isn’t on this board? Detail assignments, legacy system on-call, a working group, evidence requests, mentoring a new hire. Write the number down as a percentage. This is the step teams skip, and it is the step that produces the finding.

3. Apply a switching discount above one work context

Time split across contexts is not fungible. A conservative planning rule: subtract 10% of remaining time for a second concurrent context and 20% for a third. You don’t need to defend the precise figure — you need the plan to stop assuming that half a person on two programs equals half a person’s output on each.

4. Rebalance before commitment, and write down what you decided

Once someone shows above 100%, you have exactly four options: move the work to someone else, reduce sprint scope, formally negotiate the outside commitment down, or accept the risk and say so out loud. All four are defensible. Silently committing anyway is the only one that isn’t. Whichever you pick, record it — who was allocated, what was subtracted, and why the team committed to N points. That record is what lets you answer “why did this slip?” three months later with evidence rather than recollection.

A worked example

A six-person team at a state agency, two-week sprint, ten working days.

• Gross capacity: 6 people × 10 days = 60 person-days
• Days off: one developer on 3 days of leave, one in a 2-day training = −5 → 55
• Ceremony and overhead allowance at 15%: 55 × 0.85 ≈ 47 person-days available

Now the integrations engineer, planned at 10 days:

• Legacy interface commitment, 25% = −2.5 days
• Evidence and audit requests, historically ~1 day per sprint = −1 day
• Remaining: 6.5 days. Three concurrent contexts → apply a 20% switching discount: 6.5 × 0.8 = 5.2 effective days

The team planned on 10 days from her and will get about 5. That 4.8-day gap is roughly 10% of total team capacity — but it does not spread evenly. It lands entirely on integration stories, which is precisely where the fiscal-year milestone sits.

Translate that into delivery: if the team’s trailing three-sprint velocity is 32 points and it carries roughly 5 points of integration work per sprint into the next one, that’s 30 points of carryover over a quarter — about one entire sprint of unplanned slip against a date that was never going to move. Nobody made a bad decision. The plan simply counted a person who was already spent.

Making this repeatable inside Jira

Most teams discover over-allocation in a spreadsheet somebody maintains by hand, which means it gets done once, before an important program review, and then never again. The habit only survives if the numbers live where planning already happens.

That’s the practical case for doing capacity work inside the Jira backlog itself as part of the move to Atlassian Cloud and Atlassian Government Cloud (AGC): past velocity, days off, and per-person allocation on the same screen as the sprint you’re about to commit. Sprint planning with Capacity Planning for Jira puts those together so over-allocation shows up while you can still act on it — and so the resulting plan is a record of what the team decided, not a spreadsheet that expired the day it was emailed. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

How much productivity does context-switching actually cost a developer?
Published estimates vary widely, which is why a planning rule beats a precise claim. Use a conservative, stated discount — 10% for a second concurrent context, 20% for a third — apply it consistently, and let your own sprint history tell you whether it’s too generous.

What if I can’t reduce someone’s outside commitments?
Then reduce what you commit to. Over-allocation you can’t remove is a scope constraint, not a personnel problem. The value of measuring it is that it converts an invisible risk into a number you can put in a status report.

Isn’t this just resource management with extra steps?
Resource management usually asks who is assigned. Capacity planning asks who is actually available, after leave, ceremonies, and outside obligations. The second question is the one that predicts whether the sprint lands.

Try this before your next sprint planning

Run a 30-minute allocation audit: list each team member, write their available days after leave and overhead, ask them what else they owe this sprint, and mark anyone over 100%. If more than one name is over, you have a capacity problem, not an estimation problem — and you’ll know it before you commit rather than at the retro.

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