Short answer: Sprint capacity planning matters more in government because headcount, budget, and delivery dates are usually fixed by appropriation or contract, so a missed commitment cannot be absorbed by adding people or moving the date. Plan against the capacity your team actually has this sprint, after holidays, leave, training, and shared allocations, before you commit.

“Fewer people, same mission” is now the planning reality for many agencies. When a team shrinks through attrition, a hiring freeze, or a reduction in force, the backlog does not shrink with it. The sprint commitment that felt comfortable with eight people becomes a promise the remaining six cannot keep, and the gap shows up in a status report to someone who controls your funding.

Why does sprint capacity planning matter more in government?

Commercial teams can often trade scope, add contractors, or slip a launch. Public-sector teams usually cannot. Three constraints make the margin for error thinner:

• Fixed money and fixed dates. Fiscal-year funding, contract periods, and statutory deadlines do not move because a sprint ran long.
• Shared people. Staff are routinely detailed to other programs, split across projects, or pulled into training and mandatory activities.
• Reporting up a chain. A commitment is not a private team estimate. It becomes a number that program offices, oversight bodies, and sponsors repeat.

When commitments are based on last sprint’s velocity alone, none of these factors are visible. The team simply “does less than planned,” and nobody can say why.

How do you calculate sprint capacity in a government team?

Use a simple, repeatable sequence. It takes about thirty minutes once the habit is set.

1. Start with working days. Count the working days in the sprint for each person (a two-week sprint is ten days).
2. Subtract days off. Remove federal or state holidays, approved leave, and known training or mandatory-event days, person by person.
3. Apply allocation. If someone gives this team only half their time, count only half of their remaining days.
4. Convert with historical yield. Divide the last three sprints’ completed points by the available person-days in those sprints. This is your points-per-available-day rate.
5. Commit to the result, not the hope. Multiply this sprint’s available days by the rate, and treat that figure as the ceiling for the commitment.

What does this look like with real numbers?

Take a six-person team planning a two-week sprint that includes Veterans Day (Wednesday, November 11, 2026). Over the last three sprints the team averaged 36 completed points on 54 available person-days, a rate of about 0.67 points per available day.

• Gross capacity: 6 people × 10 days = 60 person-days.
• Holiday: 1 day each, leaving 54 person-days.
• Training: two people are out for 2 days each, leaving 50.
• Allocation: one person is 50% on another program, so their 9 remaining days count as 4.5, leaving 45.5 available person-days.
• Recommended commitment: 45.5 × 0.67 ≈ 30 points.

The habit of “we usually do 36” would have over-committed by roughly 20 percent before the sprint even started. The 30-point figure is not pessimism. It is the same productivity the team has already demonstrated, applied to the people who are actually present.

What record does a capacity decision leave behind?

Agencies increasingly value being able to show what happened, who was allocated, what changed, and what supported a decision. Capacity planning produces exactly that kind of plain record: who was on the team, which days were subtracted and why, what rate was used, and why the team committed to 30 points rather than 36. This is documentation of planning decisions, not a compliance program, but it answers the question “why did you commit to that?” without anyone reconstructing it from memory.

How does doing this in one tool inside Jira make it repeatable?

The calculation above is easy to understand and tedious to repeat. In a spreadsheet it drifts: a leave date changes, a column is overwritten, and a copy lands in someone’s inbox. Teams moving their delivery work onto Atlassian Cloud, including those planning a path to Atlassian Government Cloud (AGC), gain an opportunity to keep the capacity view next to the backlog instead of beside it.

Sprint planning with Capacity Planning for Jira puts sprint planning and team capacity on one screen inside the Jira backlog. It uses past velocity, days-off, and allocation so you can see the ceiling before you commit. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. That statement describes the Atlassian platform, not a certification held by DiViM.

A 30-minute capacity worksheet to try this week

Before your next planning meeting, build a one-page worksheet with one row per person and columns for working days, holidays, leave, training, allocation percentage, and available days. Total it, apply your three-sprint rate, and bring the resulting number to the meeting as the starting point. Do this for two sprints and the pattern becomes obvious.

FAQ

What is sprint capacity?
Sprint capacity is the amount of work a team can realistically complete in one sprint after subtracting days off, training, and time allocated to other work from its total available working days.

Is capacity the same as velocity?
No. Velocity is what a team completed in past sprints. Capacity is who is actually available this sprint. Forecasts are most reliable when velocity is converted to a per-day rate and applied to current capacity.

How often should a government team recalculate capacity?
Every sprint, before planning. Leave, holidays, detail assignments, and staffing changes shift from one sprint to the next, especially around fiscal-year boundaries.

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