Capacity-aware sprint planning means seeing past velocity, days off, and each person’s allocation together — on one screen — before the team commits to any work. Done well, it turns planning day from a morning of spreadsheet archaeology into a fifteen-minute baseline and a commitment your team can defend up the chain.

It’s 8:30 a.m. on a Wednesday at a state transportation agency, and Sprint 14 planning starts at 9:30. The scrum master has four windows open: the Jira backlog, a capacity spreadsheet, the agency leave calendar, and an email from the contracting officer’s representative explaining that the team’s business analyst is now split across two programs. Somewhere across those four windows is the team’s true capacity. The next hour goes to reconciling them — and this happens every two weeks.

Why is planning day higher-stakes in government?

In a product startup, an overcommitted sprint is an inconvenience. In a government program, the number a team commits to on planning day travels: into the program manager’s status report, onto the PMO dashboard, sometimes into an oversight briefing. Walking a commitment back costs credibility that a cautious agency agile adoption can’t spare.

Staffing pressure raises the stakes further. With hiring freezes and workforce reductions leaving many delivery teams smaller than their org charts, knowing real capacity before committing matters more, not less — fewer people, same mission. And leadership expectations are shifting in the same direction: reviewers increasingly want to know not just what you will deliver, but how you arrived at the number. A planning routine that produces a defensible record — who was available, what was subtracted, why the team committed to N points — answers both questions at once.

Here’s what that routine looks like, hour by hour.

8:30 a.m. — Assemble the three inputs

Capacity planning needs only three inputs, but they usually live in three places:

• Past velocity: completed points from the last four or five sprints — the average, not the best one.
• Days off: holidays, approved leave, and training days that fall inside the sprint window.
• Allocation: the percentage of each person’s time actually assigned to this team — rarely 100% for detailed staff and shared specialists.

If those inputs sit in separate systems, this step is the hour-long part of planning day. If they’re already on one screen, it’s ten minutes of verification.

9:30 a.m. — Set the baseline before estimating anything

The core discipline: no story discussion until the capacity number is on the wall. For Sprint 14, the math looks like this:

• Six people × ten working days = 60 nominal person-days
• State holiday for all six: −6
• One developer on three days of approved leave: −3
• Mandatory half-day security training for everyone: −3
• Business analyst allocated 60% to this program, so 40% of her remaining 8.5 days go elsewhere: −3.4

Available capacity: 44.6 person-days — about 74% of nominal. The team’s four-sprint average velocity is 33 points, but those sprints averaged roughly 52 available person-days. Scaled to this sprint: 33 × (44.6 ÷ 52) ≈ 28 points. The team plans to 28, not 33 — and can say exactly why.

10:00 a.m. — Fill the sprint against the number, not the wish

Stories come in by priority while remaining capacity counts down. Two rules keep this honest. First, stop at the number, even when a stakeholder’s favorite item sits just below the line — name it as the first candidate if capacity opens up. Second, watch individual loading, not just the team total: if a third of the committed points depend on the 60%-allocated analyst, the sprint can fail with team-level capacity to spare.

11:00 a.m. — Pressure-test, commit, record

Five minutes of pre-commitment questions: Whose leave overlaps demo prep at sprint end? Which stories depend on the part-time specialist? What gets dropped first if an emergency tasking lands mid-sprint?

Then the team commits — and records the basis: the velocity figures used, the days subtracted, the allocation percentages assumed. In an environment where reviews reward teams that can show what was decided and why, that planning record is an asset, not overhead.

3:00 p.m. — Report without reformatting

The program manager wants the sprint plan for the weekly leadership summary. When planning happened in one place, the answer is a link rather than a rebuilt slide deck — and the commitment traces cleanly back to its inputs. When a director asks in week two why the team planned 28 points instead of the usual 33, the answer takes one sentence: holiday, leave, training, allocation.

What makes this repeatable instead of heroic?

Any team can run this day once with a spreadsheet. Running it every two weeks, through personnel changes and reorganizations, is where four-window planning breaks down — the assembly step quietly grows until it crowds out the thinking.

That’s a tooling problem, and it’s one reason agencies modernizing onto Atlassian Cloud — including Atlassian Government Cloud (AGC) — are consolidating planning into the same place work is tracked. Sprint planning with Capacity Planning for Jira puts past velocity, days off, and per-person allocation on one screen inside the Jira backlog, so the 8:30 assembly step disappears and the baseline math is in front of the team before it commits. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.

FAQ

How long should sprint planning take when capacity data is ready in advance?

Sixty to ninety minutes for a two-week sprint is a reasonable target. The variable isn’t the meeting — it’s the assembly time beforehand, which one-screen capacity data shrinks from an hour to minutes.

What if the team doesn’t have velocity history yet?

For the first two or three sprints, plan directly in person-days and commit conservatively. Once three or four completed sprints exist, switch to scaling average velocity by the availability ratio shown above.

Doesn’t the baseline step slow planning down?

It adds about fifteen minutes. Mid-sprint descoping — renegotiating a commitment leadership has already reported — costs far more, in both hours and credibility.

Try the 8:30 test on your next planning day: if gathering velocity, days off, and allocation takes more than fifteen minutes, the process — not the team — is the constraint worth fixing first.

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