What does an over-allocated developer actually cost a government program? More than the hours they are short: it shows up as missed sprint commitments, rework from context switching, and quiet date slips that surface late. The fix is to cap each person’s commitments at their real availability before the sprint is committed.

A benefits-eligibility modernization team is staffed with “fewer people, same mission” after a hiring freeze. Two programs each ask for a developer’s time, both managers believe they have 60 percent of her, and nobody adds the numbers. Three sprints later, both programs are behind and each blames the other. Sound familiar?

Why is over-allocation so common in agencies?

Staffing in the public sector is often negotiated by program, not by person. Detailees, shared specialists, and part-time assignments mean one developer can appear on several rosters. Workforce reductions make this worse: the work stays, the headcount drops, and the gap is absorbed by stretching the people who remain. Because each roster looks reasonable on its own, the total is rarely checked.

What does over-allocation really cost?

There are three costs, and only the first is visible on a timesheet.

• Missed commitments. Planning against nominal time rather than real availability means the team commits to work it cannot finish.
• Context-switching loss. Splitting a day across two programs means rebuilding mental context twice. The effective output of the split is lower than the sum of its parts.
• Trust and reporting damage. Leadership hears “on track” until the sprint review shows otherwise. Each surprise makes the next status report less credible.

How do you find and fix over-allocation?

1. Build one list of every commitment per person. Include all programs, support rotations, and recurring duties. If it is not on the list, it is not planned.
2. Subtract real days off first. Federal holidays, leave, and mandatory training come out of the sprint before any allocation percentage is applied.
3. Cap total allocation at 100 percent of what remains. Any total above that is a decision for management, not a hope for the team.
4. Convert availability to points using past velocity. Use the team’s own history, not a target.
5. Record the decision. Write down who was allocated where, what was subtracted, and why the team committed to N points. That record is what you show when a sponsor asks what changed.

What does this look like with numbers?

This is an illustrative example, not a client result. A sprint has 10 working days, and one is a federal holiday, leaving 9 available days. One developer is allocated 6 days to Program A and 6 days to Program B. On paper that is 12 days of work against 9 days of availability, or 133 percent.

Suppose the team’s past velocity works out to about 2 story points per available person-day. Both programs plan as if they have the full allocation: 12 days × 2 = 24 points committed. Real capacity is 9 × 2 = 18 points. The sprint is overcommitted by 6 points, or one third more than the person can deliver, before counting any context-switching loss.

With the numbers visible, the conversation changes. The two program leads can agree to 9 days split 5 and 4, so Program A commits to 10 points and Program B to 8. Or they can escalate for another resource. Either way, the choice is made deliberately at planning time and not discovered at the sprint review.

How does doing this in Jira make it repeatable?

A spreadsheet can do this arithmetic once. Keeping it right every sprint is harder: days off change, allocations shift, and the sheet drifts from the backlog. Moving the planning into Jira, on the platform many agencies are moving to through Atlassian Cloud and Atlassian Government Cloud (AGC), keeps capacity next to the work it limits. Sprint planning with Capacity Planning for Jira shows past velocity, days off, and allocation on one screen inside the backlog, so you can see an over-allocated person before you commit. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. It records your planning decisions; it is a planning tool, not a compliance product.

Where do you start in the next 30 days?

Pick your three most-shared people. List every commitment, subtract the next sprint’s days off, and compare the total with 100 percent. Doing this for one sprint usually shows where the problem is.

FAQ

How much allocation is too much?
Any total above 100 percent of available time, after days off, is over-allocation. Many teams also hold back a margin for support work and meetings.

Is a part-time or detailed developer a problem?
No, as long as the allocation is explicit and the total across programs is checked. The risk is unrecorded split assignments.

Doesn’t over-allocation sometimes help us hit a deadline?
Short bursts can, but sustained over-allocation usually leads to rework and slips. If a date is fixed, reduce scope or add capacity instead.

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