Short answer: when requirements change mid-sprint, don’t abandon the plan — plan for the change. Reserve a defined slice of sprint capacity for mid-cycle intake (sized from your own history, not optimism), require a one-for-one capacity swap whenever new work enters, and record the trade the moment it happens. Your scope will move. Your predictability doesn’t have to.

Day 4 of a ten-day sprint. A state Medicaid modernization team is halfway through an eligibility renewal screen when the agency’s legal office issues a revised interpretation of a verification rule. It isn’t a nice-to-have and it isn’t negotiable — the new check has to be in the build that goes to UAT at the end of the month. The scrum master adds it to the sprint. Nobody removes anything. Nine days later the team delivers 19 of the 27 points it committed to, and the monthly PMO report says “team missed sprint commitment” — which is technically true and completely useless as an explanation.

Why mid-cycle change hits government teams harder

Every agile team gets interrupted. Public-sector teams get interrupted by things they cannot decline: a new statutory interpretation, an inspector general request, a legislative inquiry with a date on it, a security finding with a remediation clock, revised guidance from a funding agency. In commercial software, a mid-sprint request is usually a product decision someone can say “next sprint” to. In government, it is often an obligation with a deadline attached.

The pressure is compounding. Flat and shrinking budgets and workforce reductions across FedCiv, DoD, and state and local agencies mean the same mission is being carried by fewer people — and a team with no slack absorbs interruptions by silently dropping planned work. That is how “fewer people, same mission” turns into a delivery record nobody can explain to an oversight committee.

The fix isn’t to refuse change. It’s to make change cost something visible.

How do you plan a sprint when requirements change mid-cycle?

1. Sort the change before you size it. Not everything that arrives mid-sprint is new scope. There are three buckets: clarification (same story, sharper acceptance criteria — absorb it, no swap), new scope (work that did not exist at planning — this needs capacity), and defects on committed work (already inside that story’s cost; if it keeps happening, your estimates are the problem, not the interruptions). Teams that skip this triage treat every stakeholder question as an emergency and burn their buffer on things that were never scope.
2. Reserve an intake buffer sized from your own history. Look back six sprints. Add up the points that entered after sprint start, divide by the points committed. That percentage is your real intake rate — for most government teams under regulatory or oversight pressure it lands between 15% and 25%. Reserve that share of capacity at planning and commit the rest. This isn’t padding. It’s the observed cost of operating in your environment.
3. Make the swap rule explicit and one-for-one by capacity. When new work enters, something of equal size leaves — equal points, not equal count. A five-point emergency does not swap for a one-point cleanup story. Write the rule down and get the product owner and program manager to agree to it once, in daylight, rather than negotiating it under pressure at 4pm on day 6.
4. Re-check capacity, not just the backlog. Scope changed, but the people may have changed too. The engineer who was going to pick up the swapped-in story may be the one detailed to another program on Thursdays, or on approved leave the second week. A swap that works on the backlog and fails on the calendar isn’t a swap — it’s a deferral you’ll discover on day 9.
5. Record the trade at the moment you make it. Compliance expectations across the public sector increasingly reward organizations that can show what happened, who acted, what changed, and why. Sprint planning is not a compliance activity — but done deliberately it produces exactly that kind of record: what came in, what went out, who approved the trade, what the capacity math was, and the date. Capture it where the work lives, not in a meeting note nobody can find in November. Six months later, “why did the provider directory export slip?” has a one-line answer with a date on it.

A worked example

A six-person team on a two-week (ten working day) sprint:

• Nominal capacity: 6 × 10 = 60 person-days.
• Subtract reality: one engineer is 50% detailed to another program (−5 days), one has two days of approved leave (−2), and the whole team has a mandatory agency training day (−6). Available: 47 person-days, or 78% of nominal.
• Velocity over the last four sprints: 34, 29, 36, 31 → average 32.5, call it 32 points.
• Capacity-adjusted commitment: 32 × 0.78 ≈ 25 points.
• Intake buffer: over the last six sprints, mid-cycle work averaged 22% of committed points. Reserve 22% of 25 ≈ 5 points.
• So: commit 20 points of planned work and hold 5 points for whatever arrives.

Day 4, the revised verification rule lands. The team estimates it at 8 points. The buffer absorbs 5. The remaining 3 has to come from planned scope, so the team defers a 3-point provider directory export story to the next sprint. Planned work drops to 17. Total sprint load: 17 + 8 = 25 points — exactly the capacity the team started with.

The sprint still closes at its committed number. Velocity stays a real signal instead of a figure distorted by invisible extra work. And the PMO report doesn’t say “missed commitment” — it says the team delivered 25 points, absorbed an 8-point regulatory change on day 4, and deferred one 3-point story, approved by the product owner, to the next sprint.

Why doing this in one place makes it repeatable

None of this survives contact with a spreadsheet. The math above touches four things — past velocity, days off, allocation percentages, and the current backlog — and in most agencies those live in four places: a Jira board, a shared calendar, a resource tracker someone maintains by hand, and a planning spreadsheet that gets emailed around and is stale on arrival. When a change lands on day 4, nobody re-runs the numbers, because re-running the numbers means opening four tabs and reconciling them. So the team eyeballs it, and the record of the decision never gets written.

That’s the practical case for doing capacity planning where the backlog already is — and a big part of why agencies moving to Atlassian Cloud, including Atlassian Government Cloud (AGC), are collapsing these side systems into the platform of record. Sprint planning with Capacity Planning for Jira puts velocity, days off, and allocation on the same screen as the backlog, inside Jira, so a mid-sprint swap is a two-minute recalculation instead of a research project — and the resulting plan is a durable artifact rather than an email attachment. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

How much sprint capacity should you reserve for mid-cycle changes?
Measure, don’t guess. Add up the points injected after sprint start across your last six sprints and divide by the points committed in those sprints. Most public-sector teams under regulatory or oversight pressure land between 15% and 25%. If your rate is above 35%, the problem is usually upstream refinement or an unclear intake path — not the sprint.

Should the team just extend the sprint when a mandatory requirement arrives?
No. Moving the boundary destroys the one thing sprints give you: a fixed measuring stick. If every sprint is a different length, velocity means nothing and forecasting the fiscal year becomes guesswork. Keep the timebox and change the contents.

What if the new requirement is bigger than the entire sprint?
Then it isn’t a swap, it’s a re-plan. Cancel or reset the sprint deliberately, with the program manager in the room, and document why. A sprint that quietly limps to 40% completion does far more damage to your credibility than one you openly reset with a reason attached.

Your next step

Before your next planning session, spend twenty minutes building a one-page change budget: your last six sprints’ committed points, the points that arrived mid-cycle, and the resulting percentage. That number is your intake buffer — and it’s the most useful thing you can bring to Monday’s planning meeting.

Try it: Install Sprint planning with Capacity Planning for Jira — free · Read the help docs