Velocity is a backward-looking average of what a team has already delivered; capacity is a forward-looking estimate of what that team can realistically commit to in the next sprint, given who is actually available. Government agile teams get into trouble when they skip that second calculation and simply carry last sprint’s velocity number into planning as if it were a guarantee.

Picture a PMO lead at a state health agency walking into sprint planning with a slide that reads “our velocity is 42 points.” The team commits to 42. Two developers are out that week for mandatory security-awareness training, and the team lead has been pulled 20% onto a procurement review. The sprint closes at 29 points, the burndown chart is red in front of leadership, and nobody can explain why — because nobody planned for the training or the detail assignment in the first place. That gap between a historical number and an actual forecast is the single most common planning mistake government agile teams make.

Why This Mix-Up Costs More in Government

Velocity is an output measure: the average number of story points a team completed across recent sprints. Capacity is an availability measure: the number of working hours or points a specific team can realistically deliver in the specific sprint ahead, once days-off, training, holidays, and detail assignments are subtracted out.

Private-sector teams can usually absorb the difference. Government programs can’t as easily — fixed fiscal-year deadlines, status that rolls up a chain of command, and reporting cycles that don’t move just because a training week landed badly all make an inflated commitment visible fast. And with workforce reductions and flat or shrinking budgets showing up across FedCiv, DoD, and state and local agencies, the math only gets less forgiving: fewer people means every unplanned absence eats a larger share of the sprint.

How Do You Calculate Sprint Capacity in Government?

Capacity planning doesn’t replace velocity — it corrects it for the sprint you’re actually about to run. A simple five-step framework:

1. Start from a rolling velocity average — the last three or four sprints, not a single best one — so a lucky sprint doesn’t set an unrealistic bar.
2. Convert team size and sprint length into total person-days: number of team members multiplied by working days in the sprint.
3. Subtract known absences: approved leave, mandatory training, federal holidays, and any percentage of time team members are detailed to other work.
4. Turn the result into an availability ratio — available person-days divided by baseline person-days.
5. Apply that ratio to the velocity average to get a capacity-adjusted target, then have the team sanity-check it against the actual backlog items rather than treating it as a fixed formula.

A Worked Example: Adjusting for a Training Week

A team of six developers runs a two-week sprint: 10 working days.

• Baseline person-days: 6 × 10 = 60
• Velocity average of the last four sprints (40, 44, 38, 46): 42 points
• This sprint: one developer attends 3 days of mandatory security-awareness training, another has 4 days of approved leave, and the team lead is pulled 20% onto a procurement review — roughly 2 person-days over the sprint
• Lost person-days: 3 + 4 + 2 = 9
• Available person-days: 60 − 9 = 51
• Availability ratio: 51 ÷ 60 = 0.85
• Capacity-adjusted target: 42 × 0.85 ≈ 35.7, rounded down to 35 points

Thirty-five points — not 42 — is the number that belongs on the sprint planning slide. It’s a 17% cut from the raw velocity average, and it’s the difference between a sprint that closes green and one that closes red for reasons nobody flagged in advance.

Doing This on One Screen, Every Sprint

This calculation is simple in theory and easy to skip in practice, especially when it lives in a spreadsheet nobody updates until the sprint has already slipped. Agencies modernizing off spreadsheets and legacy Data Center tools onto Atlassian Cloud — including Atlassian Government Cloud (AGC) — get more value from capacity planning when it sits next to the backlog instead of in a separate file. Sprint Planning with Capacity Planning for Jira puts past velocity, days-off, and allocation on one screen inside the Jira backlog, so the capacity-adjusted number is visible before the team commits, not reconstructed afterward to explain a miss. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001–certified platform.

Once you have the capacity-adjusted number, the next step is to plan the sprint in Jira against that capacity rather than last sprint’s velocity. For the broader argument about which number should set the commitment, see capacity vs velocity in sprint planning.

FAQ

Is velocity a bad metric for government teams?
No. It’s a useful trailing indicator of what a team has historically delivered, but it needs a capacity adjustment before every sprint planning session — it shouldn’t be carried forward blindly as next sprint’s target.

How often should capacity be recalculated?
Every sprint. Team composition, leave, training schedules, and detail assignments shift sprint to sprint even when the roster on paper doesn’t change.

What’s the fastest way to check this without building a spreadsheet?
Take your rolling velocity average, multiply it by your team’s percent availability for the sprint (available person-days ÷ baseline person-days), and use that as your starting commitment — then adjust against the backlog in front of you.

Try it: Install free · Help docs