Key Takeaways
- The dependable way to plan sprints around federal holidays, PTO, and training days is to subtract every known non-working day person by person before committing, then size the commitment from velocity per available person-day.
- That subtraction removes a quarter to a third of assumed capacity, which is precisely the margin by which optimistic sprints miss, and smaller teams amplify it, since one absence is 17% of a six-person team but 25% of a four-person one.
- Almost none of these days are surprises, because holidays cluster from October to January, use-or-lose leave concentrates in November and December, and mandatory training is scheduled in advance, so a sprint that fails because of them is a self-inflicted miss.
- Commit from velocity per person-day, dividing recent points by the person-days that produced them and multiplying by this sprint’s adjusted days, which normalizes for past holidays instead of double-counting them; in a worked Thanksgiving sprint that turns a naive 32 into an honest 23.
- Sequence the work as subtraction first and sprint goal second, and Sprint Planning with Capacity Planning for Jira puts the whole subtraction on one screen inside the backlog so remaining capacity updates as stories are dragged in before you commit.
The dependable way to plan sprints around federal holidays, PTO, and training days is to subtract every known non-working day from the sprint, person by person, before the team commits — then size the commitment from velocity per available person-day instead of an idealized two weeks. On most government teams that subtraction removes a quarter to a third of assumed capacity, which is precisely the margin by which optimistic sprints miss.
Columbus Day lands in October, Veterans Day and Thanksgiving in November, and the federal leave year ends in early January — so use-or-lose annual leave piles into exactly the sprints that carry end-of-quarter milestones. Add the reality many FedCiv and DoD programs are living through: the team that was six people last year is four this year. Absences get heavier as teams shrink — one person out on a six-person team is 17 percent of capacity; on a four-person team it is 25. Fewer people, same mission: the calendar your team used to absorb is now a risk you have to plan.
Why is absence planning harder in government right now?
Four forces stack on top of each other.
- Holidays cluster in delivery-critical months. Eleven federal holidays a year, with the densest stretch running October through January — right where first-quarter milestones sit.
- The leave-year deadline concentrates PTO. Annual leave above the carryover ceiling is use-or-lose, so November and December sprints absorb a disproportionate share of leave — predictable in aggregate, disruptive if you discover it at standup.
- Training is mandatory and centrally scheduled. Security awareness, records management, ethics refreshers: the dates come from outside the team, but they are almost always visible before sprint planning.
- Smaller teams amplify every absence. After attrition or a hiring freeze, the same two days of leave consume a larger fraction of the sprint.
The useful part: almost none of these days are surprises on the day they happen. Every holiday, nearly all leave, and most training dates are knowable at planning time. A sprint that fails because of them is a self-inflicted miss.
How do you plan a sprint around federal holidays, PTO, and training days?
Treat it as a subtraction exercise with a fixed order of operations, run before any story is discussed.
- Sweep the calendar before planning day. Two or three days ahead, list every holiday, agency closure, all-hands, and training window that intersects the sprint, and ask each member for approved leave. Ten minutes of asking beats a week of discovering.
- Build a per-person availability line. For each member: sprint working days, minus holidays, minus leave, minus training and other committed non-sprint time. Days, not adjectives — “mostly here” is not a number.
- Apply allocation. Multiply each person’s remaining days by the share of their time actually assigned to this team. A tester detailed half-time to audit support brings 50 percent of her remaining days, however dedicated she is.
- Commit from velocity per person-day. Divide the points completed in recent sprints by the person-days the team actually had in them, then multiply that rate by this sprint’s adjusted person-days. That normalizes for past holidays instead of double-counting them.
- Record the subtraction next to the commitment. Keep the availability math with the sprint plan: who was available, what was subtracted, and why the team committed to the number it did. When leadership asks why this commitment is lower than last sprint’s, you answer with a record instead of a recollection.
Sequencing is the discipline: subtraction first, sprint goal second. Teams that pick the goal first end up negotiating with the calendar, and the calendar does not negotiate.
A worked example: committing through Thanksgiving
A four-person team — two developers, a tester, and a lead — plans a two-week sprint containing Thanksgiving. Ten working days, so nine per person after the holiday.
- Developer one takes two days of use-or-lose annual leave around the holiday: 7 days.
- Developer two has a records-management training day and a medical day: 7 days.
- The tester is detailed half-time to audit support: 9 × 0.5 = 4.5 days.
- The lead is fully available: 9 days.
Adjusted capacity is 27.5 person-days against a naive “four people, two weeks” baseline of 40 — about 69 percent. Over the last three sprints the team averaged 32 completed points while actually fielding about 38 person-days per sprint, a rate of roughly 0.84 points per person-day. The honest commitment is 27.5 × 0.84 ≈ 23 points. Committing to “our usual 32” would have overcommitted the team by roughly 40 percent — a miss engineered before the sprint started and explained at the worst possible moment, after it.
How does one screen inside Jira make this repeatable?
The arithmetic is easy; keeping it current is not. A spreadsheet leave-tracker is accurate the week it is built, then drifts — a training date moves, a detail ends early, and the model quietly diverges from the board where the work lives. That is one of the quieter arguments for finishing the move to Atlassian Cloud, or Atlassian Government Cloud (AGC) for agencies that need it: planning data belongs in the same system as the work, not in a sidecar file.
Sprint planning with Capacity Planning for Jira puts the whole subtraction on one screen inside the Jira backlog: each member’s days-off and allocation, past velocity, and remaining capacity updating as you drag stories in — before you commit. The plan itself becomes the record of what was subtracted and why. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.
FAQ
Don’t holidays already show up in our velocity?
Only on average. Raw velocity blends holiday-thinned sprints with full ones, and a Thanksgiving sprint is not an average sprint. Dividing past points by past person-days gives a rate you can apply to any calendar without double-counting.
How should we handle use-or-lose leave season?
Collect leave plans at the start of the first quarter — the federal leave year ends in early January, so the crunch is predictable months out. Plan November and December sprints at deliberately reduced capacity and, where you control sequencing, keep hard milestones out of holiday-straddling sprints.
Should mandatory training be a backlog item instead?
No. Putting training in the backlog inflates velocity with non-delivery work and corrupts the baseline you forecast from. Subtract it from capacity and let velocity measure delivery only.
Try the subtraction on your next sprint
Run the five steps by hand once — one calendar sweep, four availability lines, one division — and compare the result to what your team was about to commit. If the gap is material, make the method permanent: install Sprint planning with Capacity Planning for Jira free from the Atlassian Marketplace, or start with the help docs.




Leave a Reply
Your email is safe with us.