Aligning sprint planning with capacity planning means establishing who is actually available — after leave, holidays, details, and partial allocations — before the team commits to any work, then sizing the sprint to that number. Teams that do both in one sitting deliver predictably; teams that plan the backlog first find out mid-sprint what their real capacity was.

Picture the last sprint of the fiscal year at a federal civilian benefits program. Two positions have sat vacant since the spring workforce reduction. Three people are burning use-or-lose leave before September 30. A QA engineer is half-detailed to an audit response, and year-end data calls are landing weekly. The team lead, under pressure to close out the roadmap, commits the same scope the team carried in June — and by the retrospective, half of it has rolled over into a fiscal year that has its own plans. Nobody was lazy. The plan was simply written for a team that no longer existed that month.

Why sprint planning fails without capacity planning in government

Sprint planning decides what to build. Capacity planning decides how much building is physically possible. Commercial teams with stable rosters can blur the two. Public-sector teams cannot: availability is fragmented by federal holidays, mandated training, matrixed staff, contractor task-order gaps, and — increasingly — vacancies that stay vacant. When budgets flatten and headcount shrinks, the mission rarely shrinks with it. Fewer people, same mission means the cost of guessing at capacity has gone up, not down.

There is also an accountability dimension unique to government. A missed commitment is not just a team problem; it travels up a reporting chain to a program office, a steering committee, sometimes an oversight body. A commitment made against documented capacity is defensible. A commitment made against a full-looking roster is not.

How do you align sprint planning with capacity planning?

Run them as one meeting, in a fixed order: capacity first, backlog second. The alignment problem usually isn’t skill — it’s sequence. Here is a 60-minute agenda that cautious agile adopters can run tomorrow:

1. Capacity roll call (10 minutes). Go person by person: working days in the sprint, minus approved leave, holidays, training, and standing duties. State each person’s allocation to this team — 100%, 50%, 25%. No backlog items yet.
2. Compute the capacity ratio (5 minutes). Divide the available person-days you just counted by what a full-strength sprint would give you. This one percentage is the honest size of your sprint.
3. Set the commitment ceiling (10 minutes). Scale your recent average velocity by the capacity ratio, then hold back a buffer for unplanned work — data calls, incident response, leadership requests. The result is the most the team can responsibly commit.
4. Fill to the ceiling, not past it (25 minutes). Now open the backlog. Pull the highest-priority items until you approach the ceiling, watching per-person load as you assign — a sprint that is 80% committed overall can still have one specialist at 120%.
5. Record the number and its assumptions (10 minutes). Write down who was available, what was subtracted, and why the team committed to N points. When a detail gets extended or a vacancy announcement slips, you can show exactly which assumption changed.

That last step matters more than it looks. In a climate where agencies are expected to prove what happened, who acted, and what evidence supported a decision, a documented capacity calculation is a small, cheap piece of decision trail that answers the question before it is asked.

A worked example: sizing a fiscal-year-end sprint

Take an eight-person team on a two-week sprint — ten working days, so 80 person-days at full strength.

• A federal holiday falls in the sprint: −8 person-days.
• Use-or-lose leave across three people: −9 person-days.
• One QA engineer 50% detailed to an audit for the full sprint: −5 person-days.
• Two developers in a one-day mandatory training: −2 person-days.

Available capacity: 80 − 24 = 56 person-days, a capacity ratio of 70%. If the team’s average velocity over the last three sprints is 42 points at roughly full strength, the scaled ceiling is 42 × 0.70 ≈ 29 points. Hold back 10% for year-end data calls and the responsible commitment is about 26 points — not the 42 the roadmap wishes for. Committing 26 and delivering 26 builds more credibility with leadership than committing 42 and delivering 24 ever will.

Why doing this inside Jira makes it repeatable

Most teams that try this framework run it in a spreadsheet — and the spreadsheet is where it dies. The numbers live apart from the backlog, they go stale between ceremonies, and when the spreadsheet’s owner rotates out, the practice leaves with them. Agencies modernizing onto Atlassian Cloud — including those moving to Atlassian Government Cloud (AGC) — have a better option: keep the capacity math where the commitment happens.

Sprint Planning with Capacity Planning for Jira puts the whole agenda above on one screen inside the Jira backlog: past velocity, per-person days off, and allocation feed a live capacity picture, so you see over-allocation before you commit rather than in the retrospective. Because the plan lives with the work, every sprint leaves behind a record of who was allocated, what days off were subtracted, and why the team committed to the number it did. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

What is the difference between sprint planning and capacity planning?
Sprint planning selects and commits the work for the next iteration. Capacity planning calculates the team’s real availability — days off, allocations, holidays — for that same period. Alignment means capacity is computed first and the commitment is sized to it.

How much buffer should a government team hold?
Start at 10–15% of the scaled ceiling and adjust from evidence: if unplanned work (data calls, oversight requests, incidents) regularly consumes more, raise it. A buffer you can justify from history is easier to defend than optimism.

Does this work with story points, or only hours?
Both. With story points, scale average velocity by the capacity ratio, as in the example above. With hours, sum available hours directly and plan against that total. The principle — capacity before commitment — is the same.

Try it on your next sprint

Run the 60-minute agenda once, manually if you must: roll call, ratio, ceiling, fill, record. If your hit rate improves — it usually does — make it permanent by bringing capacity into the backlog itself.

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