Most government sprints that fail are lost before the first standup: the plan assumes working days the team never actually had. Subtracting holidays, approved leave, mandatory training, and collateral duties from each person’s availability — before committing — is the cheapest predictability improvement a public-sector team can make.

Picture a state benefits-modernization team planning the sprint that runs August 31 to September 11. Ten stories, 48 points, everyone nods. Then Labor Day removes a day for all six people, the annual cybersecurity-awareness training deadline lands mid-sprint, and one engineer reports for National Guard duty. The sprint closes at 26 points. The program office reads it as an execution problem. It was an arithmetic problem — and it was visible three weeks earlier, to anyone who counted.

Why do government teams lose more sprint days than anyone plans for?

Public-sector calendars are denser and less negotiable than most. Federal teams observe eleven federal holidays, and many states add their own. Use-or-lose leave concentrates in November and December. Mandatory training — security awareness, ethics, records management — arrives with hard deadlines. Add reserve duty, jury service, detail assignments, and standing all-hands events, and the “ten-day sprint” is often a fiction. A private-sector team can sometimes trade a day; nobody negotiates with a holiday statute or a training deadline.

Shrinking headcount makes the arithmetic harsher, not softer. When budgets flatten and teams get smaller, each absence is a larger share of capacity: on a four-person team, one person out for a week is 12.5 percent of a two-week sprint gone. Fewer people, same mission means the days-off math matters more than it ever did.

The root cause is rarely optimism — it is invisibility. Absences are approved in email, tracked in an HR portal, and announced in a training system: everywhere except the sprint plan.

How do you subtract days off before committing a sprint?

Build an absence ledger, per person, before any story is committed:

1. Inventory every absence category, not just vacation. Holidays (federal and state), approved leave, mandatory training deadlines, reserve or jury duty, onboarding and offboarding time, and standing program events all subtract real days.
2. Count per person, never as a team average. An average hides that the one engineer who knows the legacy interface is the one who is gone.
3. Apply allocation percentages after days off. A person shared 50/50 with another program contributes half of their remaining days — not half of an ideal ten.
4. Convert person-days into a commitment cap. Take points per person-day from your recent sprints, multiply by this sprint’s real person-days, and commit at or under the result.
5. Re-run the arithmetic when absences change mid-sprint. Write down what changed and why, so the retrospective compares delivery against real capacity rather than wishful capacity. That written trail — who was available, what was subtracted, why the team committed to N points — also travels well up the chain: it answers “what happened?” with evidence instead of memory.

What does the arithmetic look like in practice?

Take the six-person team above: a two-week sprint with ten working days on the calendar.

• Naive capacity: 6 people × 10 days = 60 person-days.
• Labor Day: −6 (one day, all six people) → 54.
• Team lead: two days of approved leave → −2.
• Engineer on Guard duty in week two: −5.
• Engineer shared 50/50 with a data-migration program: 9 remaining days × 50% → −4.5.
• Tester: half-day security training plus a one-day appointment → −1.5.
• Two remaining engineers: half-day training each → −1.

Real capacity: 40 person-days — two-thirds of what the naive plan assumed. The last three sprints averaged 48 points on roughly 52 person-days, or about 0.9 points per person-day. The cap is therefore 40 × 0.9 ≈ 36 points. Committing 36 and finishing 36 reads as a team in control. Committing 48 and finishing 26 reads as a team in trouble — even though the second team may have done nothing wrong except skip ten minutes of subtraction.

Why does doing this inside Jira make it repeatable?

Most teams that try this in a spreadsheet stop within a quarter. The workbook lives apart from the backlog, goes stale the day it is built, and is rarely open in the planning meeting where the commitment actually happens.

Doing the subtraction where the commitment happens changes that. Sprint planning with Capacity Planning for Jira puts each person’s days off, allocation percentage, and past velocity next to the backlog on one screen, so the cap is visible at the moment stories are dragged into the sprint — and the record of what was subtracted persists sprint over sprint. For agencies consolidating delivery tooling on Atlassian Cloud, including Atlassian Government Cloud (AGC), the app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform.

FAQ

How often will a two-week sprint contain a holiday? With eleven federal holidays spread across twenty-six two-week sprints a year, roughly four in ten sprints contain at least one — before state holidays, training deadlines, or leave. Treat the holiday check as a standing planning step, not an occasional surprise.

Should partial absences like training count? Yes. Half-day increments are enough precision, and they add up: three team members each completing a half-day mandatory course cost the sprint 1.5 person-days — about a story.

What if new absences appear mid-sprint? Update the capacity number, renegotiate scope with the product owner openly, and note the change. A sprint that descopes for a documented reason is predictable; a sprint that silently misses is not.

Before your next planning session, spend ten minutes building the absence ledger above for each team member — then let the number, not optimism, set the commitment. Try it: install Sprint planning with Capacity Planning for Jira free · help docs.