Short answer: To plan capacity around a contract or fiscal-year boundary, count the working days left before the hard date, subtract holidays, leave, and part-time allocations sprint by sprint, convert what remains into points using your past velocity per person-day, and compare that total to the scope you owe. If the margin is thin, decide now what moves, not in the last sprint.

It is October, and FY27 is three weeks old. Funds are newly available, option periods are ticking, and someone in leadership has already asked, “Will the release be done before the period of performance ends?” Most teams answer with their average velocity multiplied by the sprints left. That answer is usually wrong, because the calendar between now and the deadline is never average.

Why do fiscal-year and contract boundaries break sprint forecasts?

A hard date turns a planning estimate into a commitment. Government work adds three pressures that commercial teams rarely face at the same time: money or authority that expires on a fixed date, contract option periods that end whether or not the backlog is finished, and a calendar full of federal holidays, year-end leave, and training mandates. Add the “fewer people, same mission” reality of workforce reductions and flat budgets, and a team that shipped 42 points in a good sprint may be able to ship 30 in the next one. Average velocity hides that swing. Capacity-adjusted planning exposes it while there is still time to act.

How do you plan capacity backward from a hard date?

Work backward from the boundary, not forward from today. Five steps keep it repeatable:

1. Fix the boundary and the scope owed. Write down the exact date (end of option period, end of fiscal year, funding cutoff) and the remaining scope in the same unit you estimate in. Separate “must deliver” from “should deliver.”
2. List the sprints that fit. Count only complete sprints that end before the boundary. Reserve the last sprint, or part of it, for acceptance, handoff, and documentation rather than new features.
3. Build capacity per sprint, not per quarter. For each sprint, start with working days per person, remove federal holidays, approved leave, mandatory training, and the share of time people are allocated to other programs.
4. Convert person-days to points with a stable ratio. Divide recent velocity by the person-days the team actually had in those sprints. Use that points-per-person-day figure for the future, not the raw velocity number.
5. Compare and decide early. Add up forecast capacity across the remaining sprints and compare it to the must-deliver scope. Keep a visible margin. If the margin is under roughly 10 percent, escalate the scope trade-off now.

What does a worked example look like?

Consider an illustrative team of six on two-week sprints (10 working days each). Over its last three sprints it averaged 42 points with all six people present for all 10 days, so 60 person-days. That is 0.70 points per person-day. The option period ends after five more sprints, and 180 points of must-deliver scope remain.

The naive forecast is 42 × 5 = 210 points, a comfortable 30-point cushion. Now apply the calendar:

• Sprint 1 includes Veterans Day: 6 people × 9 days = 54. Subtract 4 days of approved leave and 4.5 days because one engineer is 50 percent allocated to another program. Capacity is 45.5 person-days × 0.70 = about 32 points.
• Sprint 2 is clean: about 40 points after minor leave.
• Sprint 3 contains Thanksgiving week: about 38 points.
• Sprint 4 spans the late-December holidays and heavy leave: about 30 points.
• Sprint 5 is a full-strength sprint: about 42 points, but part of it is reserved for acceptance and handoff.

The adjusted total is 32 + 40 + 38 + 30 + 42 = 182 points against 180 owed. The cushion shrank from 30 points to 2, about 1 percent. Nothing about the team changed; only the calendar was counted honestly. The right move is to ask the product owner now which 20 to 30 points of should-have work can slip to the next option period, rather than discovering the gap in Sprint 5.

How does a documented plan help with accountability?

Agency leaders increasingly want to see what happened, who acted, what changed, and what evidence supported a decision. A capacity plan written down before commitment is exactly that kind of record: who was allocated, which days were subtracted and why, and how the team arrived at its commitment. When scope later changes at a boundary, the trail shows the decision was informed. This is documentation practice, not a compliance outcome by itself.

Why does doing this in one tool inside Jira make it repeatable?

In a spreadsheet, every boundary means rebuilding the same model: copy the holiday list, re-key leave, re-check allocations, and hope the tab matches the backlog. As agencies move planning work to Atlassian Cloud, including Atlassian Government Cloud (AGC) for those who qualify, it makes sense to bring capacity into the backlog too. Sprint planning with Capacity Planning for Jira lets you plan sprints and team capacity on one screen, using past velocity, days off, and allocation, before you commit, inside the Jira backlog. When someone’s allocation changes or leave is approved, the capacity number moves with it, so the boundary forecast can be refreshed in minutes. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform.

A practical 90-day rollout idea

Pick the next hard date. In week one, list the remaining sprints and mark every holiday and known absence. In weeks two to four, compute your points-per-person-day ratio and run the boundary comparison above. Review it at each sprint planning meeting for the rest of the quarter, and keep the one-page result for your next status report.

FAQ

How many sprints should I reserve before a contract end date?
Reserve at least part of the final sprint for acceptance, documentation, and handoff, and avoid planning new feature work in it. Many teams hold back 10 to 20 percent of the final sprint’s capacity.

Should I use average velocity or capacity-adjusted velocity near a deadline?
Use capacity-adjusted. Convert past velocity to points per person-day, then multiply by the person-days actually available in each future sprint.

What if the forecast shows we cannot finish everything?
Raise it early with a ranked list of what can move. A documented trade-off made in October is far easier to defend than a missed date discovered in the last sprint.

Try it: Install free on the Atlassian Marketplace · Help docs