To plan sprint capacity around a contract or fiscal-year boundary, build a per-person boundary ledger, plan the quarter’s sprints backward from the boundary date, model the incumbent-to-successor overlap as partial allocation rather than full headcount, and record the assumptions with the commitment. The goal is a sprint plan that reflects who will actually be on systems on each day, not who is on the org chart.

A state agency’s licensing-modernization team has run two-week sprints for a year. Its fiscal year ends June 30. The development contract was recompeted, a new vendor won, and the transition window is the last two weeks of June. Procurement sees no gap in coverage. The scrum master sees nine names on a board for a sprint in which perhaps five and a half people will do sprint work.

Why do contract boundaries hit state and local teams differently?

Federal teams mostly plan around September 30. State and local teams face a wider spread: 46 states close their fiscal year on June 30, and others on March 31, August 31, or September 30, with counties and cities adding their own calendars. Layer on contract vehicles with different periods of performance, and a single team can cross three funding boundaries in one year.

Recompetes make it worse. A vendor change is not one person leaving; it is a subteam leaving and a subteam arriving, often with an overlap that looks like double capacity on paper and behaves like half capacity in practice. With budgets flat and many agencies operating with fewer staff than a year ago, the internal people who used to absorb transitions now have less room to do so. Knowing real capacity before committing matters more, not less.

How do you plan sprint capacity across a fiscal-year or contract boundary?

1. Build a boundary ledger, one row per person. Columns: name, employer (agency or vendor), contract vehicle, period-of-performance end, option status (exercised, pending, none), funding source, and earliest confirmed day on systems after the boundary. Fill it at quarter start and update it at every refinement. The ledger moves information from contract files to where sprint decisions are made.
2. Plan backward from the boundary. Identify the last sprint that ends before the boundary and treat it as the last full-strength sprint of the quarter. Schedule feature work that needs the whole team there. Reserve the boundary sprint for work that survives a thin team: hardening, documentation, defect burn-down, and knowledge transfer itself.
3. Model overlap as partial allocation, not headcount. During a vendor transition, departing engineers spend their final days transferring knowledge and offboarding; arriving engineers spend their first days on access, environments, and codebase orientation. Put both on the plan at a realistic percentage. A common starting point is 50% for departing staff in their final week and 25–35% for new staff in their first sprint, then adjust from what your team actually observes.
4. Separate capacity from work eligibility. If the new fiscal year opens with unapproved budgets or a pending purchase order, the constraint is usually on what may start, not on who is present. Keep the capacity numbers honest and maintain a constrained backlog of already-funded work to draw from until funding clears.
5. Write the commitment memo. One short note per boundary sprint: who was allocated at what percentage, which days were subtracted and why, the velocity used, and the resulting commitment. When the post-transition review asks why July delivery dipped, you answer from a record of what was decided, who decided it, and what evidence supported it.

A worked example: a vendor transition across June 30

Take a six-person team, two state employees and four contractors from the incumbent vendor, planning a sprint from June 22 to July 3, 2026. July 3 is the observed Independence Day holiday, so the sprint has nine working days. The incumbent’s contract ends June 30, day seven of the sprint. The successor vendor places three engineers on June 22 with a two-week overlap.

Naively, the board shows nine people for nine days: 81 person-days. Now do the ledger math:

• Two state employees: 2 × 9 = 18 days, minus 2 days one of them owes to year-end procurement close: 16
• Four incumbent contractors: 7 days each through June 30 = 28, minus 50% on their final three days for knowledge transfer (−6): 22
• Three successor engineers: 9 days each at 30% ramp-up allocation: about 8

That is 46 person-days, not 81. Apply the team’s usual 75% focus factor for ceremonies, support tickets, and interruptions, and you have roughly 34.5 effective person-days. If the previous three sprints averaged 38 points on about 48 effective person-days, the team’s rate is roughly 0.79 points per effective person-day. The honest forecast for the boundary sprint is 34.5 × 0.79, or about 27 points. The team commits 27, reserves the sprint for hardening and handoff, and the PMO hears the number and the reasoning on June 22 rather than a surprise on July 6.

Why does doing this in Jira make it repeatable?

The ledger and the arithmetic are simple. The difficulty is keeping them current across a quarter of leave requests, contract modifications, and staffing changes, especially when the spreadsheet lives with one person who is also on the boundary ledger. As agencies consolidate delivery onto Atlassian Cloud, including Atlassian Government Cloud (AGC), planning capacity where the backlog already lives removes that maintenance burden. 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 a departing contractor’s last day and a new engineer’s 30% ramp show up in the capacity number before the team commits, and each sprint’s plan remains as a record afterward. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified platform.

FAQ

Should we run a sprint at all during a vendor transition?

Yes, but scope it for the team you will actually have. A short, hardening-focused sprint keeps cadence, gives new engineers real tickets to learn on, and produces a clean baseline for the successor’s first full sprint.

How do we handle a fiscal-year boundary when the option year is not yet signed?

Plan the affected people at zero capacity from the boundary date until you have a confirmed start, and keep a variant plan ready to promote when the paperwork lands. Optimistic assumptions about signatures are the most common cause of boundary-sprint failure.

What if our state’s fiscal year does not end June 30?

The method is the same; only the date changes. The ledger approach also handles mid-year contract boundaries that have nothing to do with the fiscal calendar.

Start with a 90-day boundary runway

This week, build the boundary ledger for everyone on your team and mark every sprint in the next 90 days that touches a contract end, option date, or fiscal close. Designate the last full-strength sprint before each boundary and decide now what the boundary sprint will hold. Then let the per-person arithmetic run inside Jira: install the app free from the Atlassian Marketplace and see the help docs for setup.

Try it: Install free · Help docs

← More sprint & capacity planning guides for public-sector teams