Sprint capacity planning matters more in government than anywhere else because commitments are made against fixed appropriations, fiscal-year deadlines, and oversight that turns a missed sprint into a reportable slip — while the team’s real availability almost never matches its headcount. The teams that stay predictable plan every sprint from measured capacity, not remembered velocity.

With the federal fiscal year ending September 30, many program offices are entering the last sprints of FY26 with fewer people than they started it. Picture a seven-developer modernization team that lost two engineers to an early-retirement offer and a backfill freeze. The backlog didn’t shrink. The milestone dates didn’t move. And at the next program review, someone will ask whether the September commitments still hold. How the team answers — with a number it can defend or a number it remembers — is the difference between agile surviving in that agency and agile getting blamed.

Why is sprint capacity planning harder in government than in industry?

Commercial agile assumes a stable, dedicated team and the ability to hire when demand grows. Government teams operate under the opposite conditions. Rosters blend civil servants, contractors tied to specific task orders, and detailees who can be recalled with a memo. Sprint time quietly leaks into duties that never appear on the board: security refreshers, data-call responses, IV&V sessions, audit support, mandatory training.

And when capacity falls short, there is no quick fix. Budgets are appropriated in advance, contract ceilings are fixed, and a hiring action can take months — so a capacity gap discovered mid-sprint cannot be bought away; it can only be absorbed by the schedule. Meanwhile the commitment has usually traveled: into a program plan, a milestone briefing, sometimes a public roadmap. In that environment, an optimistic sprint plan isn’t a private team matter. It’s a future explanation someone will owe.

What does “fewer people, same mission” do to velocity?

Workforce reductions and flat budgets are pushing many agencies to deliver the same mission with smaller teams. That makes one quiet fact about velocity suddenly dangerous: velocity is a trailing measurement of a specific roster. When two of seven developers leave, the team’s velocity history describes a team that no longer exists.

The common failure mode is social, not mathematical. Under pressure to reassure leadership, the team keeps committing to its old average. It misses. It misses again. By the third miss, skeptics aren’t blaming arithmetic — they’re blaming agile. A smaller team that commits to what it can actually deliver protects both its people and the credibility of the method.

How do you plan sprint capacity for a smaller government team?

Recalibrating takes five steps and about twenty minutes:

1. Turn past velocity into a rate. Divide average velocity from recent sprints by the person-days that produced it. The result — points per person-day — survives roster changes; raw velocity doesn’t.
2. Count this sprint’s real person-days. Start from working days per person, then subtract days off, federal holidays, and training, and reduce anyone splitting time across programs by their actual allocation percentage.
3. Multiply, and let the math set the commitment. The mission’s urgency doesn’t add hours to anyone’s week. Committing above capacity doesn’t signal ambition; it schedules a miss.
4. Record the assumptions. Note who was counted at what allocation, which days were subtracted, and why the team committed to N points. When someone asks in September why August’s commitment was 20 points, the answer should be on record, not in someone’s memory.
5. Recalculate whenever the roster changes. A new detail, a departure, a returning team member — each changes the denominator. Re-run the numbers before the next commitment, not after the next miss.

A worked example: recalibrating after losing two developers

The seven-person team above delivered 33, 35, and 37 points in its last three normal sprints — call it 35 — across ten-day sprints, or 70 person-days. That’s a rate of 0.5 points per person-day.

Now the sprint ahead: five developers remain. One is allocated 50% to another program, contributing 5 person-days instead of 10. Another has four days of approved leave, contributing 6. Real capacity: (3 × 10) + 5 + 6 = 41 person-days. At 0.5 points per person-day, the defensible commitment is about 20 points — not the remembered 35. A team that commits to 35 starts the sprint roughly 70% overcommitted and finds out in the burndown. Check the individual view too: 20 points spread so that one developer carries half of them is a plan that fails a different way.

How do you make this repeatable inside Jira?

Most teams that try this discipline in a spreadsheet abandon it by the third sprint — the spreadsheet lives outside the backlog, goes stale with every schedule change, and belongs to whoever built it. As agencies consolidate delivery work onto Atlassian Cloud and Atlassian Government Cloud (AGC), the practical fix is to plan capacity where the work already lives. That’s what Sprint planning with Capacity Planning for Jira does: past velocity, per-person allocation, days off, and the capacity-versus-commitment picture on one screen inside the Jira backlog, before the team commits. Each sprint’s plan doubles as a record of what was assumed — useful the next time a program review asks how a commitment was set. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.

A practical way to start: pull your last three sprint velocities, count next sprint’s true person-days, and see how far the two numbers have drifted. That twenty-minute exercise is the whole case for capacity planning, made with your own data.

FAQ

Is capacity planning the same as tracking velocity?

No. Velocity measures output after a sprint; capacity estimates input before it. Velocity is most useful converted into a rate — points per person-day — that keeps capacity math accurate when availability changes.

Should a government team re-baseline velocity after losing staff?

Yes — immediately, not after a few failed sprints. Convert old velocity into a per-person-day rate and scale it by the new roster’s real person-days. Averaging sprints delivered by a larger team guarantees overcommitment.

Does this work with hours instead of story points?

Yes. The unit doesn’t matter; the discipline does — subtract real availability first, commit second. Teams whose PMO mandates hours can run the same five steps with hours as the rate.

Try it: Install Sprint planning with Capacity Planning for Jira free · Read the help docs