Short answer: Days-off planning prevents sprint failure by subtracting holidays, leave, and training from the sprint’s person-days before the team commits, so the commitment matches the hours people can actually work. Teams that skip this step overcommit by 10–20% on any sprint that contains a holiday or a training week.

It is the second week of October. Monday is a federal holiday, two developers are in mandatory annual security training, and one is on pre-approved leave. The sprint still says “10 working days” in the planning meeting, and the team commits to the same 36 points it delivered last time. By Thursday everyone knows it will not land, and the status report to leadership says “behind.” Nothing went wrong with the work. The plan was wrong on day one.

Why does days-off planning matter so much in government?

Public-sector calendars are dense with fixed, non-negotiable absences: federal or state holidays, mandatory annual training, furlough-risk periods, and fiscal-year-end “use it or lose it” leave surges. These are known weeks in advance, which makes a missed forecast hard to defend. With workforce reductions and flat budgets, “fewer people, same mission” is the reality for many agencies, and a smaller team has less slack to absorb a miscalculated sprint.

Accountability matters too. When a program office reports up a chain, “we committed 36 points and delivered 29” invites questions. “We had 49 available person-days, committed 32, and delivered 31” is a record that explains itself.

How do you plan sprint capacity around days off?

Use this five-step framework at every sprint planning session:

1. Start with gross person-days. Team members multiplied by working days in the sprint. Six people over a 10-day sprint is 60 person-days.
2. Subtract holidays for everyone. A holiday removes one day per person, not one day per team. Check the agency calendar, not just the federal one.
3. Subtract approved leave and training. Collect these before planning day, not during it. Include half-days and partial allocations to other programs.
4. Calculate available person-days. This is the number that drives the commitment.
5. Convert with past velocity per available person-day. Divide recent delivered points by recent available person-days, then apply the rate to this sprint.

Two habits make this reliable: keep the days-off list in one shared place that the whole team can see, and review it again on the first day of the sprint, since leave changes.

What does the math look like? A worked example

A six-person team runs a 10-day sprint. Over the last three sprints it delivered 34, 38, and 36 points (average 36) with about 54 available person-days each, which is roughly 0.67 points per available person-day.

• Gross capacity: 6 people × 10 days = 60 person-days
• Holiday (Monday): 6 × 1 = 6 days
• Security training: 2 people × 1 day = 2 days
• Approved leave: 3 days
• Available: 60 − 6 − 2 − 3 = 49 person-days
• Forecast: 49 × 0.67 ≈ 32 points

The team that copies last sprint’s 36 points overcommits by 4 points, about 12%. That is exactly the margin that turns “on track” into “slipped” at the sprint review. Planning at 32 gives the product owner an honest trade-off up front: which four points of backlog move to the next sprint.

Where do teams usually go wrong?

Three patterns come up repeatedly. First, the days-off list lives in a spreadsheet or in someone’s head, so it is stale by planning day. Second, teams treat velocity as a constant instead of a rate tied to available time. Third, partial availability gets ignored: a developer who is 50% allocated to another program and out two days is not a full contributor, even though they appear on the board.

For modernization programs moving off spreadsheets and toward Atlassian Cloud, this is often the first place the manual process breaks: the capacity workbook and the Jira board drift apart.

How does doing this inside Jira make it repeatable?

When capacity lives in a separate file, the calculation has to be rebuilt every sprint and nobody trusts yesterday’s version. Sprint planning with Capacity Planning for Jira puts the sprint, the team’s past velocity, days-off, and allocation on one screen inside the Jira backlog, so the available person-days and the forecast are visible while you are choosing what to pull in. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. As a side effect, the planning decision is recorded alongside the work: who was allocated, which days off were subtracted, and why the team committed to that number. That is a useful decision trail for reporting up the chain, though the app records planning decisions; it is not a compliance product.

FAQ

How far ahead should we collect days off?
Ask for the next two sprints’ leave and training at every sprint planning, and confirm again on day one of the sprint.

Should holidays reduce velocity or capacity?
Capacity. Velocity is the output rate; holidays change how many person-days are available to produce it.

Do we need a focus factor on top of this?
Not necessarily. If you derive velocity per available person-day from recent sprints, normal meeting and support load is already inside that rate.

Try it: Install free · Help docs