Sprint capacity planning matters more in government than anywhere else because a missed sprint there isn’t just a schedule slip — it’s a commitment that already traveled into a program plan, a budget justification, or a briefing to people who don’t forgive surprises. Teams that survive scrutiny plan every sprint from measured, real availability, not from headcount or last quarter’s memory.

A nine-person state Department of Transportation team modernizing a permitting system walks into a routine two-week sprint. Nothing about the backlog changed. But statewide IT runs a mandatory two-day cybersecurity training that week, one engineer gets pulled 50% onto a legislative data request, and two more have approved leave already on the calendar. The team still has nine names on the roster. It does not have nine people’s worth of sprint.

What actually breaks a sprint plan in a government agency?

Commercial sprint planning assumes a stable team that shows up full-time and stays that way. Government teams rarely match that picture. Rosters mix career staff, contractors bound to specific task orders, and detailees who can be pulled back to their home office with a day’s notice. Layered on top are obligations that never show up on the board — mandatory training, data calls, audit support, committee work — that consume real hours without producing a single story point.

Headcount-based planning misses all of this. Counting nine people as nine people’s worth of sprint isn’t optimism, it’s a miscount, and the gap between the miscount and reality shows up mid-sprint, when it’s hardest to fix.

Why does a missed sprint cost more here than in industry?

Three conditions raise the stakes for government teams specifically:

• Money doesn’t flex mid-year. Budgets are appropriated in advance and contract ceilings are fixed. A capacity shortfall can’t be solved by spending more; it can only be absorbed by the schedule, and a hiring action to backfill it can take months.
• Commitments travel upward. A sprint goal often becomes a line in a program status report or a milestone briefed to oversight. A quiet internal miss can become a very visible external one.
• Agile’s credibility is still on trial. Long-tail adopters are often a few missed sprints away from someone in leadership deciding agile “doesn’t work here.” Predictability is what keeps the method in place long enough to prove itself.

How do you build a capacity plan you can actually defend?

The fix isn’t more process — it’s sequencing the same planning meeting differently. Five steps, done before anyone pulls a ticket:

1. Establish real availability first. For each person, start with working days in the sprint, then subtract holidays, approved leave, training, and any known pull toward other duties.
2. Convert history into a rate, not a target. Divide recent delivered points by the person-days that produced them. Points per person-day survives roster and schedule changes; a flat velocity average doesn’t.
3. Multiply real capacity by the rate. That product is the sprint’s defensible commitment — not a round number, not last sprint’s total, not what leadership hopes to see.
4. Check allocation at the individual level. A team can hit its aggregate capacity number while one person carries 60% of the points. That imbalance is where burnout and slips actually happen.
5. Write down the assumptions. Record who was counted at what availability and why the team landed on that number. The next time someone asks how a commitment was set, the answer is on record, not in someone’s memory.

A worked example: a state permitting-system team recalculates

The nine-person team above has delivered 54, 58, and 50 points in its last three normal two-week sprints, averaging 54 points against roughly 80 person-days of capacity in each — a rate of about 0.675 points per person-day.

This sprint looks different. The mandatory two-day training subtracts 18 person-days across the team. One engineer pulled 50% onto the legislative data request contributes 5 person-days instead of 10. Two others have a combined 6 days of approved leave. Real capacity: 90 nominal person-days minus 29 lost equals 61 person-days — about 68% of the sprint’s headline capacity.

At 0.675 points per person-day, the defensible commitment is roughly 41 points. A team that instead commits based on headcount — nine people, ten days, the usual rate — lands near 61 points and starts the sprint about 49% overcommitted before a single ticket moves. The gap between 41 and 61 is exactly the part that used to get discovered in the burndown chart instead of the planning meeting.

How do you make this the default instead of a one-time exercise?

The math above takes twenty minutes with a calculator, which is exactly why it tends to happen once and then quietly stop — a spreadsheet lives outside the backlog, goes stale the moment someone’s schedule changes, and depends on whoever remembers to update it. As agencies consolidate delivery work onto Atlassian Cloud and Atlassian Government Cloud (AGC), the more durable fix is planning capacity where the sprint itself lives. That’s what Sprint planning with Capacity Planning for Jira is built for: past velocity, per-person allocation, and days off on one screen inside the Jira backlog, before the team commits. Each sprint’s plan doubles as the record of what was assumed going in — useful the next time a program review asks how a number was set. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.

A practical starting point for any team reading this before its next planning session: pull the last three sprints’ velocity, count this sprint’s real person-days against the calendar you already have, and see how far apart the two numbers land. That gap is the whole argument for capacity planning, built from your own data.

FAQ

Is capacity planning just a more careful version of velocity tracking?
No. Velocity measures what a team delivered after the fact; capacity estimates what it can realistically deliver before the sprint starts. The two connect through a rate — points per person-day — that lets a velocity history stay useful even as the roster or schedule changes.

What if training, leave, and details vary every single sprint?
That’s normal in government teams, which is exactly why capacity should be recalculated every sprint rather than assumed from an average. A five-minute recalculation before planning is far cheaper than a missed commitment after it.

Does this approach require switching from story points to hours?
No. The unit is a team’s choice — points, hours, or person-days all work the same way. What matters is subtracting real, known unavailability before committing, not the label on the number.

Try it: Install free · Help docs