Open a federal calendar in any given quarter and you will find it pockmarked with days your team is not actually working. Juneteenth, Independence Day, a Monday holiday that creates a “use-or-lose” travel weekend, a mandatory cybersecurity training block, two engineers detailed to an inspector-general data pull, and a contractor whose badge renewal eats half a day. None of that shows up in a story-point estimate. Yet it is precisely why sprints in government slip when, on paper, the math looked fine.
Most agile teams plan capacity as if every sprint were a clean two weeks of full availability. In a public-sector environment, that assumption is almost never true, and the gap between assumed and actual working days is the single most common reason a committed sprint quietly under-delivers. Below is a practical way to plan around the days your people are genuinely away.
Why government calendars punish optimistic planning
Three things make agency calendars harder to plan around than the typical commercial team’s. First, federal holidays cluster: between mid-November and early January, a two-week sprint can lose three or four working days to holidays alone. Second, training and compliance time is non-negotiable and often scheduled with little notice, from annual security awareness courses to records-management refreshers. Third, your team is rarely all yours, as detailees, part-time staff, and people splitting time across programs come and go on schedules you do not control.
The result is a “phantom capacity” problem. The team believes it has ten working days. In reality it has six and a half once you subtract a holiday, a training block, and one developer’s pre-approved leave. Commit to ten days of work and you will carry the difference into the next sprint, where it compounds.
A four-step framework for honest capacity
You do not need a heavy process to fix this. You need to subtract reality before you commit, not after. Here is a sequence that takes about fifteen minutes at the top of planning.
- Start from the calendar, not the backlog. Before anyone discusses stories, lay the sprint’s actual working days against the federal holiday schedule and any agency-specific closures. Mark them off first so the holidays are subtracted before optimism enters the room.
- Collect every day-off and known absence. Ask each team member for approved leave, medical appointments, jury duty, and travel inside the sprint window. Capture it as days, not vague “I might be out Thursday” hedges.
- Subtract committed non-sprint time. Training, all-hands, certification study, oversight requests, and standing program meetings all consume hours that cannot go to sprint work. Treat them as scheduled absences, because functionally they are.
- Convert remaining days to a capacity number, then plan to it. Multiply each person’s available days by their realistic focus factor (the share of a workday that actually becomes delivery, usually 0.6 to 0.7 after meetings and email), and only then pull stories to match.
The discipline that matters most is sequencing. Holidays and leave come off the top, before the team gets attached to a sprint goal. It is far easier to right-size a commitment up front than to explain a miss to a program manager who only saw the original plan.
A worked example
Take a five-person team planning a two-week (ten working day) sprint that straddles a federal holiday.
- Ten working days minus one holiday leaves nine potential days per person.
- Two developers each take one day of pre-approved leave; one is out for a two-day certification course.
- The whole team owes four hours to mandatory annual security training, roughly half a day each.
Raw availability looks like 5 people times 9 days, or 45 person-days. Subtract the leave (2 days), the certification (2 days), and the training (5 people times 0.5 day, or 2.5 days), and you are at 38.5 person-days. Apply a 0.65 focus factor and you land near 25 effective delivery-days. If this team’s history says one effective day yields about one story point, they should commit to roughly 25 points, not the 40-plus that a “five people, two weeks” gut estimate would suggest. That difference, almost 40 percent, is the gap between a sprint that closes clean and one that bleeds carryover into the next fiscal checkpoint.
Why this belongs in one place, inside Jira
Done in a spreadsheet, this calculation is accurate exactly once. The next sprint, someone forgets to update the holiday row, a detailee’s schedule changes, and the model drifts from the board where the work actually lives. The fix is to plan capacity in the same screen as the backlog, so days-off and allocation sit next to the stories you are committing to.
That is what Sprint planning with Capacity Planning for Jira is built for. It lets you set each person’s days-off and allocation, pulls in past velocity, and shows remaining capacity against the sprint as you drag work in, all on one screen inside the Jira backlog before you commit. Holidays and leave stop being a thing you remember to subtract and become part of the plan by default. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform, which keeps your security reviewers comfortable while your scrum master keeps the commitment honest.
The bottom line
In government, the calendar is a stakeholder. Plan as if every working day is available and you will routinely over-commit by a third or more, then spend retros explaining variance that was baked in before sprint one. Subtract holidays, leave, and training first, convert what remains into a real capacity number, and commit to that. It is a small change in sequence that produces a large change in predictability, and predictability is the currency you report up the chain.
Try it: Install free · Help docs
Leave a Reply
Your email is safe with us.