Aligning sprint planning with capacity planning means working out the team’s real available hours — after leave, mandatory training, and time detailed to other priorities — before the sprint goal is set, not after it is missed. For a government team operating on a fixed budget and a fiscal-year deadline, that ordering is the difference between a commitment the program office can rely on and one you have to walk back two weeks later.

Picture a state Department of Motor Vehicles modernization team, eight developers, coming off three straight sprints averaging 48 story points. Going into sprint 12, the scrum master sets a 50-point goal based on that trend line. Halfway through, one developer is out for annual leave, two lose a day each to a mandatory cybersecurity refresher, and a third is pulled onto a production incident. The team closes at 34 points. Nothing about the plan was unreasonable — it just never asked the one question that would have caught the shortfall: how many hours did this team actually have this sprint?

Why sprint planning and capacity planning drift apart in government teams

In most public-sector shops, sprint planning and capacity planning live in different places. Velocity gets tracked in Jira. Leave requests sit in an HR system or a shared calendar. Training schedules come from a compliance office email. Details to another program are tracked, if at all, in a spreadsheet someone updates when they remember. By the time the team sits down to plan, capacity is a guess dressed up as a number.

That gap matters more here than in the private sector. A commercial team that overcommits absorbs the miss quietly and adjusts next sprint. A government team reports predictability up a chain — to a PMO, a program executive, sometimes a congressional or legislative oversight body — and a missed sprint goal becomes a line item someone has to explain. With workforce levels flat or shrinking across FedCiv, DoD, and state agencies, and more work landing on fewer people, the agencies that get this right treat capacity as the input to planning, not the excuse afterward.

How do you align sprint planning with capacity planning?

The fix is a sequence, not a tool. Five steps, run in order, before the sprint planning meeting starts:

1. Calculate net capacity first, in person-days. Start from total team member-days in the sprint, then subtract confirmed leave, mandatory training, holidays, and any known detail to another team or program. What’s left is what the team actually has to work with.
2. Pull a rolling velocity trend, not a single sprint’s number. Average the last three to six sprints, adjusted for the capacity each of those sprints actually had, so you’re comparing throughput per available day rather than a raw point total that happened to include a light sprint.
3. Convert the trend into a capacity-adjusted target. Multiply the rolling throughput rate by this sprint’s net available days. That’s the number the team commits to — not the average of recent sprints, and not the backlog priority owner’s wish list.
4. Reserve a scope-change buffer. Government sprints absorb mid-cycle requirement changes more often than teams like to admit — a policy clarification, a new audit finding, a stakeholder request. Holding back 10–15% of capacity for this keeps a single change from blowing the whole sprint.
5. Record the capacity assumptions behind the commitment. Who was allocated, what days-off were subtracted, and why the team landed on this number. That record isn’t a compliance certification of anything — it’s a plain decision trail that answers “why did we commit to this” when someone asks weeks later.

A worked example: capacity-aligned planning for an 8-person team

Back to the DMV team. An 8-person team in a 10-working-day sprint has 80 gross person-days. Subtract 5 days for one developer’s approved leave, 2 days for the cybersecurity refresher split across two people, and 3 days for the developer pulled to the production incident. Net available capacity: 70 person-days, not 80.

Their rolling throughput, measured across the last four sprints against actual available days rather than the theoretical 80, works out to roughly 0.68 points per person-day. Applied to this sprint’s 70 available days, that’s a capacity-adjusted target of about 47 points — close to, but meaningfully below, the 50-point goal the team would have set from trend line alone. Hold back 10% as a scope buffer and the real commitment lands closer to 42 points. That’s a number the team can actually hit, and one the PMO can build a fiscal-year forecast on without getting burned.

Doing this on one screen inside Jira

The reason this alignment breaks down in practice isn’t that the math is hard — it’s that the inputs live in four different places and someone has to reconcile them by hand before every sprint planning session. Sprint planning with Capacity Planning for Jira puts past velocity, days-off, and allocation on one screen inside the backlog you’re already planning from, so the net-capacity number is sitting right next to the sprint goal before anyone commits to it. It’s Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001-certified cloud platform, which matters if your agency is already moving toward Atlassian Government Cloud as part of a broader modernization push off spreadsheets and legacy tools.

FAQ

What’s the difference between velocity and capacity?
Velocity is how many points a team has historically completed per sprint. Capacity is how many person-days the team actually has available in the upcoming sprint, after leave, training, and details are subtracted. Velocity tells you a rate; capacity tells you how much of that rate applies right now.

How often should a government team recalculate capacity?
Every sprint, not just quarterly. Leave, training calendars, and details to other programs shift sprint to sprint, and a capacity number calculated once at the start of a fiscal year goes stale fast, especially around holiday clusters and mandatory training seasons.

Does documenting capacity decisions help with audits?
It creates a plain record of who was allocated, what time off was subtracted, and why the team committed to a given number — useful when a PMO or auditor asks how a commitment was reached. It’s a documentation practice, not a compliance certification, and it won’t substitute for your agency’s own audit or ATO processes.

Try it: Install free · Help docs

Related guide: want a pre-sprint checklist to run through before the meeting starts? See our sprint planning checklist for government scrum masters.