Contract and fiscal-year boundaries change how many people a sprint actually has — sometimes mid-sprint. The fix is to map every period-of-performance end date, option-year start, and the September 30 fiscal cutoff onto your sprint calendar, then calculate each person’s available days on each side of the boundary before the team commits.

It is the third week of September. The sprint board shows nine avatars, the backlog is refined, and planning is going smoothly — until someone mentions that five of those nine people sit on a task order whose period of performance ends on the 30th, eight days into the sprint. The option year is funded but not yet signed, and nobody can say which day those five will be back on systems. The plan assumed a team that, for the last two days of the sprint, may not exist.

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

Sprint planning quietly assumes the team on day one is the team on day ten. In most government programs that assumption fails on a schedule you can predict: task orders and periods of performance end on fixed dates, option years begin with paperwork lag, recompetes swap whole subteams, and September 30 reshapes everyone’s calendar at once. Federal staff absorb fiscal-year closeout duties. Use-or-lose annual leave clusters into late September. The first sprints of October often start under a continuing resolution that limits which work may begin.

None of this is a surprise the way an outage is a surprise — the dates are known months ahead. The failure is that they live in contract files and HR calendars, not in the sprint plan. And with budgets flat and teams running leaner than a year ago, the slack that used to absorb these cliffs is gone. Fewer people, same mission: when staffing is thin, knowing real capacity before you commit matters more, not less.

How do you plan sprint capacity across contract and fiscal-year boundaries?

1. Map the cliffs two quarters out. Put four kinds of dates on the team calendar: every period-of-performance end date for anyone on the team, option-year exercise dates, September 30, and the realistic continuing-resolution window. A boundary you can see six sprints away is a staffing plan; one you discover mid-sprint is an incident.
2. Split any straddling sprint at the boundary. Count each person’s working days on each side rather than averaging. A contractor whose period ends on day eight contributes zero capacity to the final integration-and-test days — exactly where sprints are won or lost. The average says “80% available”; the plan needs to know which 80%.
3. Discount for transition overhead on both sides. Departing people spend their final days on knowledge transfer and offboarding — plan their last week at half capacity for sprint work. Arriving people need badges, accounts, and context — plan a new contractor at 25–50% for the first sprint or two, and expect even continuing contractors to lose time to option-year administration.
4. Hold a continuing-resolution variant of the October backlog. A CR usually doesn’t remove people; it restricts which work may start. Keep a constrained backlog — sustainment, in-flight work, security patches — sized to full capacity, and a full variant to promote if appropriations pass. Deciding this at refinement beats improvising it in week one of the fiscal year.
5. Record the assumptions with the commitment. Who was allocated at what percentage, which days off were subtracted, what discounts applied, and why the team committed to N points. When November’s review asks why Q4 velocity dipped, you answer from a record rather than memory — the same evidence discipline agencies are pushed toward everywhere else: show what happened, who acted, and what supported the decision.

A worked example: one sprint across September 30

Consider an eight-person team running a two-week sprint from September 21 to October 2, 2026 — ten working days, with the fiscal-year boundary falling after day eight. Three members are federal employees; five are contractors on a task order ending September 30. The option year is exercised, but two of the five contractors roll off at the boundary, with replacements starting mid-October.

Ideal capacity is 8 × 10 = 80 person-days. Now subtract:

• Two departing contractors miss days 9–10 (October 1–2): −4
• Their last three days run at 50% for knowledge transfer: −3
• Three continuing contractors lose half a day each to option-year admin: −1.5
• One federal member has two days of fiscal closeout duties: −2
• Another takes three days of use-or-lose leave: −3

That leaves 66.5 person-days. Apply the team’s normal 80% focus factor (ceremonies, support, unplanned work) and you get roughly 53 effective person-days — about two-thirds of the naive 80. If the last three sprints averaged 42 points on about 64 effective person-days (≈0.66 points per person-day), the honest forecast is 53 × 0.66 ≈ 35 points. Commit 35, and tell stakeholders why before the sprint starts, not at the review.

Why is this easier on one screen in Jira?

The arithmetic is not hard; sustaining it is. A capacity spreadsheet is accurate the week it is built, then drifts — leave requests land, a contract mod slips, the owner rotates off, and the numbers quietly detach from the backlog they are supposed to govern. As agencies consolidate delivery onto Atlassian Cloud, including Atlassian Government Cloud (AGC), the practical move is to plan where the work already lives. Sprint planning with Capacity Planning for Jira puts past velocity, per-person days off, and allocation percentages on one screen inside the Jira backlog, so the team sees real capacity — boundary effects included — before it commits, and keeps each sprint’s plan as a record afterward. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform.

FAQ

Should a sprint ever straddle the fiscal-year boundary?

Avoid it when you can — ending a sprint on or near September 30 is cleanest. If your cadence must straddle it, plan capacity separately for each side of the boundary rather than averaging across it. An honest 35-point commitment beats a hopeful 42.

How early should we plan for a contract transition?

Map boundaries two quarters out and re-check at every refinement. Treat any sprint within 30 days of a period-of-performance end as affected: onboarding a replacement — badging, accounts, system access — routinely takes two to six weeks, so the capacity dip starts before the exit date and outlasts it.

Does a continuing resolution reduce sprint capacity?

Usually not directly — people generally stay, but the work they may start changes. Treat capacity and backlog eligibility as separate questions: keep the capacity numbers as they are and swap in the constrained backlog variant until appropriations pass.

Start with a 30-minute boundary audit

This week, list every contract and period-of-performance end date for the people on your team, add option-year dates and September 30, and flag every sprint in the next two quarters that touches one of them. That list is your Q4 risk register. Then let the per-person math run inside Jira: install Sprint planning with Capacity Planning for Jira free from the Atlassian Marketplace and see the help docs for setup.

admin

See Full Bio