The reliable way to plan a sprint around holidays, leave, and training days is to subtract every known non-working day from each person’s calendar before the sprint goal is discussed, then commit from a velocity rate measured in points per available person-day rather than an assumed two weeks. Skip that subtraction and the commitment is really a bet against the calendar — one the calendar usually wins.

A regional Veterans Affairs claims-processing team learned this the hard way going into a sprint that opened with the Martin Luther King Jr. Day holiday. On paper the sprint looked normal: five people, ten working days, the same commitment as always. By the second week it was clear the team had planned the sprint that existed on the calendar, not the one that actually happened — and leadership wanted to know why a routine sprint had slipped.

Why does absence planning break government sprints more than most?

Four things compound in ways a generic agile guide rarely mentions.

• The federal and state holiday calendar is front-loaded. MLK Day, Presidents’ Day, and a cluster of state observances all land in the first calendar quarter — exactly when many agencies are also trying to show early-year progress against annual goals.
• Training is mandatory, centrally scheduled, and non-negotiable. Annual ethics briefings, records-management refreshers, and security-awareness modules get assigned by a compliance office on a date the team does not control, but that date is almost always visible weeks ahead.
• Detailing people across programs is routine. A business analyst spending part of the sprint supporting an audit, or a tester split across two teams, is normal in government staffing — and each detail quietly reduces the days that person actually has for this sprint.
• Smaller teams feel every absence harder. Workforce reductions and hiring freezes across FedCiv, DoD, and state agencies mean the same two days of training or leave now consume a larger share of a smaller team’s capacity than they did two years ago. Fewer people means the same mission has to be planned more precisely, not less.

None of this is unpredictable in aggregate — holidays are fixed a year out, training dates are usually published a sprint or two in advance, and details are known staffing decisions. The miss happens when none of it gets subtracted before the team commits.

How do you plan a sprint around holidays, leave, and training days?

1. Sweep the calendar before planning day. A few days ahead of sprint planning, list every holiday, agency-wide training date, and approved leave request that falls inside the sprint window. Ask directly — don’t wait for it to surface at standup.
2. Build an availability line per person. Start with sprint working days, subtract holidays, subtract approved leave, subtract mandatory training. The result is a number of days, not a description like “should be around most of the time.”
3. Apply each person’s allocation to this team. Someone detailed 40 percent of their time to another effort brings 60 percent of their remaining days to this sprint’s capacity, no matter how available they seem in standup.
4. Commit from a measured rate, not a habit. Divide points completed in recent sprints by the person-days those sprints actually had, then apply that rate to this sprint’s adjusted person-days. That accounts for past absences instead of quietly repeating them.
5. Keep the subtraction attached to the commitment. Store who was available, what was subtracted, and why the team landed on its number alongside the sprint plan itself. When a program manager asks why this sprint’s commitment is lower than usual, the answer is a record, not a guess.

The order matters: subtract first, set the goal second. Teams that pick a target number before accounting for the calendar end up negotiating with reality mid-sprint instead of planning around it up front.

A worked example: MLK Day plus mandatory training

The claims-processing team above has five people on a two-week sprint that opens with MLK Day, leaving nine working days per person before any other subtraction.

• Developer A is out two days for a pre-approved family commitment: 7 days.
• Developer B has one day of annual ethics training and one day of a records-management refresher: 7 days.
• The business analyst is detailed 40 percent of her time to a separate audit-prep effort this sprint: 9 × 0.6 = 5.4 days.
• The QA tester has no absences this sprint: 9 days.
• The scrum master splits time between process work and coding, contributing at roughly 50 percent allocation to delivery: 9 × 0.5 = 4.5 days.

Adjusted capacity comes to 32.9 person-days, against a naive “five people, nine days” baseline of 45 — about 73 percent. Over its last three sprints the team completed an average of 36 points while fielding roughly 40 person-days each time, a rate of 0.9 points per person-day. Applied to this sprint’s 32.9 adjusted person-days, the honest commitment is about 30 points. Committing to the usual 36 would have overcommitted the team by roughly 20 percent — the exact size of the miss leadership eventually asked about.

How does doing this on one screen inside Jira keep it repeatable?

The math above isn’t hard; keeping it current is. A leave spreadsheet is accurate the day it’s built and stale a week later, once a training date shifts or a detail ends early — and by then it has drifted from the backlog where the actual work lives. That gap is one more reason agencies are consolidating planning inside Atlassian Cloud, including Atlassian Government Cloud (AGC) where that’s the required environment, rather than maintaining a parallel tracking file.

Sprint planning with Capacity Planning for Jira puts each person’s days-off, allocation, and past velocity on one screen inside the Jira backlog, updating remaining capacity as stories are pulled in — before the sprint is committed. Because the plan lives with the backlog, the subtraction and the commitment stay attached to each other by default, rather than depending on someone remembering to copy the leave tracker over. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

Doesn’t average velocity already absorb holidays and training?
Only if your sprints are interchangeable, and a sprint opening on MLK Day isn’t. Blended velocity understates capacity in a light sprint and overstates it in a heavy one. Measuring points per person-day and reapplying that rate to the actual calendar avoids both errors.

What about training dates that get added after planning?
Treat them the way you’d treat a late-arriving leave request: adjust the affected person’s availability line and, if the shortfall is material, revisit the commitment rather than absorbing it silently and explaining a miss later.

Should mandatory training count as sprint work?
No. Logging it as a backlog item inflates velocity with non-delivery time and corrupts the baseline every future sprint gets forecast from. Subtract it from capacity and let velocity measure delivery only.

Try it on your next sprint

Run the subtraction by hand once — one calendar sweep, one availability line per person, one division — and compare it to what the team was about to commit to. If the gap is real, make the method permanent instead of a one-time exercise.

Try it: Install free · Help docs