Short answer: When a requirement changes mid-sprint, run a capacity-checked swap rather than a re-plan — size the new work, remove an equal number of points from stories nobody has started yet, confirm the team still has the working days left to finish, and record what was traded and who approved it. Cancel and re-plan only when the change invalidates the sprint goal itself or when it exceeds roughly a quarter of the committed points.

Four working days into a two-week sprint, a guidance letter lands in the program manager’s inbox. The income-verification rule your team is halfway through building now has an extra condition. Nobody is arguing about whether to do it — the agency has no choice. The only real question is what the team stops doing to make room, and whether anyone will be able to explain that trade three months from now when the delivery report goes up the chain.

Why mid-cycle change hits public-sector teams harder

Commercial teams absorb changing requirements by moving a date. Government teams usually cannot. The fiscal year ends when it ends, the contract period of performance ends when it ends, and the milestone in the program plan was briefed to someone above your director. So the pressure lands on scope — and the path of least resistance is to quietly add the new work on top of an already-full sprint and hope the team makes it up.

That habit is expensive twice over. The first cost is delivery: a sprint that started at a realistic commitment and ended 30% over is a sprint that will miss, and a team that misses three sprints running loses the ability to forecast anything. The second cost is documentation. Agencies are under real pressure right now to show their work — who acted, what changed, and what evidence supports the decision. A sprint whose scope silently drifted mid-cycle leaves no answer to “why did the reporting module slip a month?” other than someone’s memory.

Add the current staffing reality — flat budgets, hiring freezes, people detailed onto audit responses and incident reporting — and the margin for absorbing surprise work has largely disappeared. Fewer people, same mission means knowing your real capacity matters more, not less.

How do you handle a mid-sprint requirement change without blowing up the sprint?

Use the same five steps every time. The consistency is the point: a repeatable protocol is what turns a disruption into a documented decision instead of an argument.

1. Classify the change before you touch the board. Is it a genuinely new requirement, a clarification of something already in scope, a defect in work you already delivered, or scope creep with no authority behind it? Only the first one earns a swap. Clarifications get folded into the existing story. Defects go to the defect budget you should already be reserving. Scope creep goes to the backlog with a polite note about the next planning session.
2. Size it before you accept it. Refine and estimate the new work in the same units the team already uses. “It’s small” is not a size. If the team cannot size it inside fifteen minutes, it is not ready to enter this sprint — put it at the top of refinement for the next one.
3. Swap, never add. Remove an equal number of points from stories nobody has started. Untouched work is the only work you can pull without wasting effort already spent. Removing a half-finished story converts real hours into nothing.
4. Re-check remaining capacity, not original capacity. The commitment you made on day one assumed ten working days. On day four you have six left, minus whatever days-off land in that window. Compare the remaining point total against the days that are actually left, not against the sprint you planned.
5. Write the trade down where the decision lives. One line is enough: date, what came in, what went out, who approved it. Put it on the sprint record — not in a chat thread that scrolls away.

When should you cancel the sprint instead?

Swapping is the default. Cancel and re-plan only when one of these is true:

• The change invalidates the sprint goal — the team is no longer building the thing the sprint was for.
• The incoming work exceeds roughly 25% of the committed points, which means you would be gutting the sprint rather than adjusting it.
• There is not enough unstarted work left to swap against, so any exchange would throw away work in progress.

A worked example: the 32-point sprint that stayed a 32-point sprint

A state Medicaid eligibility modernization team runs two-week sprints with six people.

• Rolling three-sprint velocity: 41, 36, 40 → average 39 points.
• Baseline availability: 6 people × 10 working days = 60 person-days.
• Subtractions this sprint: 3 days of mandatory security training (one person), 2 days PTO (one person), and one engineer detailed 50% to an audit response (5 days) = 10 person-days lost.
• Available: 50 of 60 person-days = 83% capacity.
• Capacity-adjusted commitment: 39 × 0.83 ≈ 32 points.

On day 4, the income-verification change arrives. The team sizes it at 8 points — exactly 25% of the commitment, right at the cancel-versus-swap line. The scrum master checks the board: 13 points are done, 11 are in progress, and 8 points sit untouched as a 5-point reporting story and a 3-point notification story. Both are pulled. The sprint is still a 32-point sprint. Remaining work is 19 points against six working days at the same 83% availability — consistent with the 3.2-points-per-day the team has been running.

The sprint record gets one line: Day 4 — added ELIG-418 (income verification rule change, 8 pts) per state guidance letter dated 14 Aug; removed ELIG-392 (5) and ELIG-397 (3), neither started; approved by program manager. That sentence is what makes the next status briefing a two-minute conversation instead of an investigation.

Why this is easier to repeat inside Jira

The protocol above is arithmetic, and arithmetic done in a side spreadsheet gets skipped the moment a sprint is under stress — which is precisely when it matters. That is the practical argument for doing planning where the work already lives, and it is the same argument driving agencies off Data Center and spreadsheets and onto Atlassian Cloud and Atlassian Government Cloud: fewer systems to reconcile, one place the record actually sits.

Sprint planning with Capacity Planning for Jira puts velocity, days-off, allocation, and the sprint backlog on one screen inside the Jira backlog, so a mid-sprint swap takes a minute: see the new total against remaining availability before you accept the change, not after. It is a Cloud Fortified app running on Atlassian’s SOC 2 Type II / ISO 27001 platform. It does not make your program compliant with anything — it makes the planning decisions visible and recorded, which is the part teams usually lose.

FAQ

Should we ever just absorb a small change without swapping anything?
Only if the change is genuinely a clarification of work already committed. If it adds testable behavior, it has a size, and something equal has to come out. “Small” changes absorbed three times in one sprint are how a 32-point commitment quietly becomes a 40-point one.

How do we stop leadership from treating mid-sprint changes as free?
Show the trade, not the complaint. A running log of “in / out / approved by” over a quarter is far more persuasive than any single conversation, because it makes the cost of interruption visible as a list of deferred features with names and dates attached.

What if the change comes from a source we cannot refuse — a statute, a court order, an OMB memo?
Nothing changes about the method. You still size it, you still swap against it, and you still record it. The team is not deciding whether the work happens; it is documenting what was displaced so the schedule impact is understood before someone is surprised by it.

Try this next sprint

Make a one-page mid-sprint change slip with five fields: date, what came in, points, what went out, who approved. Use it for every change for one quarter. At the quarterly review, bring the stack. It is the cheapest predictability artifact a government team can produce, and it costs about ninety seconds per change.

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