Sprint failure on a government team rarely traces back to bad estimates — it traces back to a calendar nobody subtracted. When holidays, PTO, and mandatory training quietly remove a fifth of a sprint’s working days and the plan still assumes every day is available, the sprint is committed to fall short before anyone writes a single story. Subtracting real days off before the team commits is the fix.

Picture the sprint 14 review. The burndown flattened around day six, three stories carried over, and the PMO has to explain to a division director why the team missed a commitment it made three weeks earlier. Nothing broke. No requirement changed. Two analysts spent two days in mandatory records-management training, and the sprint spanned a state holiday nobody had blocked out on the board. The team didn’t fail to deliver — the plan failed to account for the days it never had.

Why Do Sprint Commitments Break Without Days-Off Planning?

Government calendars are dense in ways most sprint templates don’t anticipate: federal or state holidays, annual mandatory training such as security awareness, ethics, records management, and EEO refreshers, staff detailed or loaned to other programs, jury duty, compressed RDO schedules, and PTO that clusters around fiscal year-end. Many teams still plan sprints against a flat assumption — ten working days and three developers means thirty dev-days — without netting out what’s actually on the calendar. That shortcut works fine until a training-heavy or holiday-heavy sprint arrives, and the same velocity that worked last time suddenly produces a miss. The team didn’t get slower. The days-off assumption was just never made explicit.

The stakes are higher now than they used to be. With flat or shrinking headcount across many FedCiv, DoD, and state programs, there’s less slack in the roster to absorb an unplanned absence, so every day off is a larger share of a smaller team’s total capacity.

How Do You Build Days-Off Planning Into a Sprint Commitment?

A five-step framework works for teams of any size:

1. Start from the real calendar for the sprint window. Mark the holidays, any furlough or RDO days, and known blackout dates before anyone estimates a story.
2. List every known individual absence by name and day. Approved PTO, mandatory training, jury duty, court dates, and pre-scheduled appointments are usually calendared weeks in advance, so there’s rarely a good reason for one to be a surprise at sprint planning.
3. Convert net available days into capacity using real throughput. A team member who reliably closes 1.2 points per available day contributes differently than someone still ramping up; a flat one-point-per-day rule hides that.
4. Hold back a small reserve for unplanned leave. Even disciplined calendaring can’t predict a sick day. A team that plans to its last available hour has no room to absorb one without slipping the sprint goal.
5. Revisit the number if leave changes mid-sprint. Recalculate and say the trade-off out loud in stand-up — descope or flag the risk — instead of letting it surface silently at review.

What Does This Look Like With Real Numbers?

A six-person applications team at a state transportation agency is planning a two-week, ten-working-day sprint. Gross capacity, if every day were available to everyone, is 6 × 10 = 60 person-days. Against the real calendar, the team has:

• One state holiday during the sprint — 6 person-days lost, since it hits the whole team the same day
• One developer’s pre-approved PTO — 3 person-days
• Two analysts’ mandatory quarterly records-management training — 4 person-days combined

That’s 13 person-days off, leaving net capacity of 47 person-days — about 78% of the gross figure. At the team’s historical throughput of 0.75 points per person-day, net capacity is roughly 35 points. Planning off the gross number instead would have suggested 45 points — a 10-point overcommitment, about 29% more than the team could actually deliver. That gap is exactly the size of two or three stories carried into the next sprint, and it’s the same gap that shows up as a “missed commitment” on a leadership dashboard.

Running these numbers by hand in a spreadsheet works for one sprint. It breaks down across a program running several concurrent sprints on Atlassian Government Cloud, where days-off assumptions live in someone’s inbox instead of next to the backlog. Sprint planning with Capacity Planning for Jira puts the team’s calendar, days-off, and net capacity on the same screen where backlog items get pulled into the sprint — so the number the team commits to already has holidays, training, and PTO subtracted before the sprint starts, not after the burndown flattens. Because those assumptions are entered and saved with the sprint itself, there’s also a plain record of why the team committed to 35 points instead of 45 — useful the next time someone asks.

Before installing anything, you can run a fifteen-minute version of this yourself: block your team’s known absences for the next sprint on a calendar, subtract them from each person’s working days, and multiply by their average points-per-day. If that number is meaningfully below what you were about to commit to, the sprint was already overcommitted.

FAQ

How do you calculate available days for a sprint with holidays and PTO?

Start with the sprint’s total working days, then subtract every known absence individually: holidays (which typically remove a day from the whole team at once), individual PTO, mandatory training, and any other calendared leave. What’s left is net available person-days — use that, not the sprint’s nominal length, as the basis for capacity.

Should capacity planning account for unplanned leave too?

You can’t plan for a specific unplanned absence, but you can reserve a small buffer for it. Many teams hold back roughly 5–10% of net capacity so a sick day or emergency doesn’t automatically turn into a missed commitment.

How often should days-off assumptions be revisited during a sprint?

At minimum, whenever new leave is approved mid-sprint. Treat it like a scope change: recalculate capacity and surface the trade-off in stand-up rather than letting it appear as a surprise at sprint review.

Try it: Install free · Help docs