Five anti-patterns account for most sprint planning failures on government agile teams: carrying unfinished work forward without subtracting it, letting one person absorb the overflow, committing to work nobody has refined, ignoring the standing support workload, and accepting a commitment the team never validated. All five are visible in your last retrospective, and all five are corrected the same way — by calculating real capacity, out loud, before the team commits.

Here is a pattern that shows up constantly in agency retrospectives. A team runs three-week sprints and never quite finishes one. Planning opens with last sprint’s leftovers and ends by adding about as much new work as before. The burndown never reaches zero. Nobody is careless — the team is planning as though each sprint starts with an empty board and a full roster, and neither is true.

Why do planning anti-patterns cost more in government?

In a commercial product team, a missed sprint is absorbed internally and the roadmap shifts a week. In an agency the commitment travels: it becomes a line in a status report, a slide in a quarterly review, sometimes a contract milestone — and when it slips, the question comes from above, in writing, months later. The margin has narrowed, too. With workforce reductions and flat budgets across FedCiv, DoD, and State & Local, many teams carry the same mission with fewer people. Slack in the system used to absorb a sloppy plan; now it produces a visible miss.

What are the five anti-patterns — and how do you fix each?

1. The invisible carryover

Symptom: The burndown never reaches zero, and planning always begins by triaging leftovers.

Carryover feels like it has already been paid for — the work is half done, so teams treat it as free. It is not. Unfinished work is the first claim on the next sprint’s capacity, and it arrives with re-orientation cost attached.

Fix: Compute capacity first, subtract the points remaining on carried-over items, then decide how much new work fits in what is left.

2. The hero buffer

Symptom: The same person’s name is on the last three items that “saved” the sprint, and throughput collapses when they take leave.

Overcommitment does not always show up as a miss. Sometimes one senior person absorbs it by working evenings, which hides the planning problem and creates a continuity risk: if they are detailed elsewhere or retire, delivery drops overnight.

Fix: Plan to team capacity, not individual heroics. A plan that only works if one person gives up their weekend is a forecast of burnout.

3. Committing to unrefined work

Symptom: Items enter the sprint at epic size with a placeholder estimate, to be broken down “once we get into it.”

Refinement is the first ceremony sacrificed when the calendar gets tight, and the cost is deferred rather than avoided. Work decomposed mid-sprint almost always turns out bigger than the placeholder — and by then the commitment is public.

Fix: Set an entry bar: nothing enters a sprint unless it is estimated and small enough to plausibly finish inside it. Split before you commit, not after.

4. The unbudgeted support tax

Symptom: “We got pulled onto other things” is a recurring retrospective line.

This one is disproportionately a public-sector problem. Teams carry production support for citizen-facing systems, records requests, audit evidence requests, patch cycles, and incident-reporting obligations that arrive on a clock. None of it is optional, none of it is on the sprint board, so it displaces planned work invisibly.

Fix: Measure it for two sprints, then reserve it — name someone on support rotation and remove them from the capacity pool, or take a flat percentage off the top.

5. The proxy commitment

Symptom: Ask the team where the sprint number came from and you get a shrug.

In matrixed agency environments — a PMO, a program manager, and a prime contractor lead all with a stake in the plan — the commitment often gets assembled outside the room and handed to the team. People do not defend numbers they did not help produce.

Fix: The people doing the work set the commitment, and the plan records what produced it: who was allocated, at what percentage, which days were subtracted, and what velocity was assumed. When the question returns in a program review months later, the answer should be a record, not a memory.

How do you calculate a realistic commitment?

Take a five-person team planning a two-week sprint, with eight points of unfinished work rolling in.

• Naive capacity: 5 people × 10 working days = 50 person-days
• One engineer on support rotation all sprint: −10
• Two members allocated 60% to this program: −8 (each loses 4 of their 10 days)
• One analyst on approved leave: −2
• One developer in acquisition training: −3

Real capacity: 27 person-days, just over half the naive figure. If the last four sprints averaged 26 points on roughly 33 available person-days, the team’s rate is about 0.8 points per person-day — so this sprint’s capacity is 27 × 0.8 ≈ 21 points.

Now subtract the carryover. Eight points are already spoken for, leaving 13 points of new work — half of what the team delivered last sprint. That is not bad news. It is the first honest input leadership has had all quarter, and it arrives early enough to re-scope or ask for help.

How do you make this repeatable inside Jira?

Every fix above is arithmetic, not insight. The failure mode is where the arithmetic lives: a side spreadsheet that goes stale, disagrees with the backlog, and disappears when the scrum master rotates out. As agencies modernize onto Atlassian Cloud and Atlassian Government Cloud (AGC), the practical move is to do this math where the work already sits. Sprint Planning with Capacity Planning for Jira puts past velocity, per-person allocation, and days off on one screen inside the Jira backlog, so the team sees real capacity before it commits — and each sprint leaves a record of the assumptions behind the number. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.

A practical place to start: at your next retrospective, ask three questions — how many points carried over and were they subtracted before committing, how much time went to unplanned support, and can everyone here explain where the commitment number came from. Whichever produces the longest silence is the anti-pattern to fix first.

FAQ

How much carryover is normal?
Some is inevitable. A consistent pattern — a fifth or more rolling over, sprint after sprint — signals that the commitment is too large, not that the team is slow.

Should we reserve capacity for support work, or handle it as it arrives?
Reserve it. Unreserved support work does not disappear; it silently displaces planned work and resurfaces as a miss nobody can account for.

Our team is smaller than last year but the deadlines did not move. What do we do?
Recalculate from the current roster and show the gap early, in numbers. “We are behind” invites doubt; “we have 27 person-days against 40 person-days of scope” is a negotiable fact that gives leadership time to reprioritize.

Try it: Install free · Help docs