Short answer: A capacity-aware sprint planning day is one where the team walks in with velocity, days-off, and allocation already visible on a single screen, spends the session deciding what to commit to instead of reconstructing arithmetic, and walks out with a written number and the reasoning behind it. For most government teams it takes about 90 minutes — roughly half what the spreadsheet-and-whiteboard version takes.

It is 8:45 on a Tuesday at a state Department of Labor. The unemployment insurance modernization team has planning at 9:00. The scrum master is in a spreadsheet, reconciling a leave calendar from HR against a Jira board against a Teams message about who got pulled onto the legislative data call. She will not finish before the meeting starts. The team will spend the first forty minutes watching her do math on a whiteboard, then commit to a number that feels about right.

Two sprints later, the same team is done by 10:20 and nobody opened a spreadsheet. Here is what changed.

What does a capacity-aware sprint planning day actually look like?

The shift is not a new ceremony. It is moving the arithmetic out of the meeting and into the backlog, so the meeting is only about judgment.

8:45 — the pre-read

Fifteen minutes before the session, the scrum master opens the capacity view on the backlog and checks three things: the sprint’s working days, who is off, and who is allocated below 100%. She is not calculating. She is confirming that what the tool shows matches what she knows — that Devon really is at half time for the legislative data call, that the mandatory security awareness training really is landing this sprint. Corrections take two minutes because they are made in one place.

9:00 — establish the real working days first

The team does not start with stories. It starts with the calendar. The sprint runs ten working days on paper. After a state holiday, one person’s approved leave, a half-day of agency-wide training, and a detail assignment, it is materially fewer. Naming this out loud in the first five minutes prevents every downstream argument about whether the team is "sandbagging."

9:20 — separate headcount from allocation

This is where public-sector teams lose the most. Six names on a board is not six people of capacity. A new analyst three weeks into onboarding is not a full unit. A developer splitting time between the sprint and a FOIA response is not a full unit. Allocation percentages make the difference visible instead of leaving it as a private worry each person carries into the room.

9:45 — pull work until the bar fills, then stop

With a real capacity number on screen, backlog pulling becomes mechanical. The product owner pulls in priority order. The team watches the committed total rise against the available total. When the bar fills, the pulling stops. The conversation that follows — "we can take the interface rewrite or the claimant notice fix, not both" — is the conversation leadership actually needs, and it happens in the room instead of in a status report six weeks later.

10:15 — write down the commitment and the reasoning

The last five minutes are the ones teams skip and later regret. Record the committed total, the available capacity it was based on, and the one or two things that were deliberately left out. That record is what you hand a program manager in November when they ask why a milestone moved.

How do you calculate the number? A worked example

The Department of Labor team, six people, a two-week sprint with ten working days on paper:

• Nominal capacity: 6 people × 10 days = 60 person-days
• State holiday, everyone: −6 → 54
• Maria, three days approved leave: −3 → 51
• Devon, detailed at 50% to a legislative data call: −4.5 → 46.5
• Agency-wide security awareness training, half a day each: −3 → 43.5
• Priya, five weeks into onboarding, counted at 50%: −4.5 → 39 person-days available

Thirty-nine of sixty — 65% of the paper number. Now bring in history. The last three sprints delivered 34, 29, and 32 points, averaging 32, across an average of 48 available person-days. That is a throughput rate of 32 ÷ 48 = 0.67 points per person-day.

Applied to this sprint: 39 × 0.67 ≈ 26 points.

Twenty-six, not thirty-two. A team that plans on last sprint’s velocity alone walks in aiming at 32 and finishes at 26, and the miss gets reported upward as a performance problem rather than what it actually was — a calendar the plan never accounted for.

Why does doing this in one place matter?

Every step above is possible with a spreadsheet, a leave calendar, and a disciplined scrum master. Plenty of agencies run it that way. The problem is that it survives exactly as long as that person does. When they rotate off the program, take a detail, or leave in a workforce reduction, the method leaves with them, and the next sprint reverts to gut feel.

This is the practical argument for doing planning inside the tool the work already lives in, as part of the broader move to Atlassian Cloud and Atlassian Government Cloud (AGC). When velocity, days-off, and allocation are all fields on the backlog screen, the practice belongs to the team rather than to one person’s spreadsheet. And it produces something agencies increasingly need for their own reasons: a durable record of who was allocated, what time was subtracted, and why the team committed to the number it did. That is a decision trail, not a compliance artifact — but when a program manager, an IG reviewer, or an incoming contractor asks how a commitment was set, having the answer already written down is worth a great deal.

Sprint planning with Capacity Planning for Jira puts velocity, days-off, and allocation on the same screen as the backlog. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform.

FAQ

How long should a capacity-aware sprint planning session take?
For a two-week sprint with a team of five to eight, budget 60–90 minutes once the capacity data is already visible. Most of the time saved comes from not reconstructing the calendar in the room. If you are still spending more than 20 minutes on arithmetic, the inputs are living in too many places.

What if our team’s velocity history is unreliable or nonexistent?
Use available person-days as your planning unit for the first three or four sprints and track what actually completes. After three sprints you will have a defensible points-per-person-day rate. Do not borrow a rate from another team — team composition, domain, and estimation habits make cross-team rates meaningless.

Our staffing just got cut. Does capacity planning still matter?
It matters more. When a team loses two of eight people but keeps the same mission and the same fiscal-year milestones, guessing at capacity is how you end up committing to the old number and missing publicly. Knowing the real available capacity is what lets you have the scope conversation early, while there is still time to change something.

Try this in your next sprint

Before your next planning session, build a five-line capacity worksheet: nominal person-days, minus holidays, minus approved leave, minus training and mandatory time, minus partial allocations. Compare the result to the number you were about to commit to. If the gap is more than 15%, you have found your predictability problem.

Try it: Install Sprint planning with Capacity Planning for Jira — free · Read the help docs