The most expensive part of an overcommitted sprint isn’t the work that slips — it’s the chain reaction afterward: unfinished work corrupts your velocity data, corrupted data wrecks your forecasts, and missed forecasts erode the leadership trust your agile adoption depends on. The fix costs one planning conversation: measure real capacity first, and commit only to what the numbers support.
It’s early August, which means the question is already circulating: “Can we fit one more increment in before September 30?” Picture a state transportation team modernizing a permitting system on grant funds that expire at fiscal year-end. Eight engineers, two-week sprints, a leadership chain that reads every burndown. Saying yes to everything feels mission-minded. But a yes built on headcount and optimism, rather than measured capacity, is the kind of yes the program pays for all winter.
What does overcommitment actually cost a government program?
A missed sprint looks like a one-time event. It isn’t. The cost compounds in four ways:
- It corrupts your planning data. When half the sprint rolls over, “planned” and “delivered” blur. After three overcommitted sprints, nobody knows the team’s real velocity — and every quarterly forecast built on that number inherits the noise.
- It spends credibility you can’t expense. In an agency, the third missed commitment in a row rarely produces coaching; it produces oversight — extra status meetings, spreadsheet reporting, and a quiet reversion to the waterfall habits agile was supposed to replace.
- It taxes quality silently. Teams defending a doomed commitment cut the invisible work first: testing, documentation, peer review. In government, that bill arrives later — as rework, and as gaps in the record when a reviewer asks for evidence.
- It burns people you can’t backfill. With hiring freezes and workforce reductions across FedCiv, DoD, and State & Local, “fewer people, same mission” is the operating reality. Sustained crunch plus a months-long backfill cycle turns each resignation into a capacity cliff.
How do you stop overcommitting? Five guard-rails
Overcommitment is prevented before planning ends, not during the sprint. Run these five checks every time:
- Plan the team you’ll actually have. Do the calendar math: working days, minus federal and state holidays, approved leave, mandatory training, and time detailed to other programs. The unit that matters is person-days available, not headcount.
- Use a velocity range, not a single number. Pull the last five completed sprints and note the worst, median, and best. Commit at or below the median. Teams remember their best sprint; the data remembers all of them.
- Discount shared people realistically. An engineer allocated 50% to your program does not deliver half of a full workload — context switching taxes both halves. Count partial allocations conservatively, and revisit the assumption when results disagree.
- Commit to the floor, stretch to the ceiling. Commit the number your capacity math supports, then name two or three stretch items to pull in only when committed work is done. Stretch items preserve ambition without betting your delivery record on it.
- Write the decision down. Record who was available, what was subtracted, and why the commitment is N points. When someone up the chain asks “why only N?”, subtraction math is the answer that ends the meeting.
A worked example: the sprint that “felt like” 44 points
Back to that transportation team: eight people, ten working days — 80 nominal person-days. Now the subtractions:
- Labor Day holiday: −8 person-days
- Two engineers detailed half-time to a legacy-system cutover: −10
- One engineer on four days of approved leave: −4
- Mandatory annual training, a half-day for everyone: −4
That leaves 54 person-days — about two-thirds of nominal. The last five sprints scored 27, 31, 36, 38, and 44 points, earned at an average of roughly 66 available person-days per sprint — about 0.53 points per person-day. This sprint’s math: 54 × 0.53 ≈ 29 points. So the team commits 29 and names stretch items up to about 35. The optimistic plan — “we’ve hit 44 before” — would have overcommitted by half, and the burndown would have told leadership all about it.
Why one screen inside Jira beats the side spreadsheet
None of this arithmetic is difficult. It gets skipped because the inputs live in four places: the HR leave calendar, a staffing tracker, last quarter’s velocity report, and whoever remembers the training schedule. As agencies consolidate delivery work into Atlassian Cloud, the practical move is to put the capacity math where the backlog already lives. Sprint planning with Capacity Planning for Jira shows past velocity, days-off, and per-person allocation on one screen inside the Jira backlog, so the commitment conversation happens against real numbers — before anyone commits. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.
There’s a governance dividend, too: planning this way leaves a record of who was allocated, which days off were subtracted, and why the team committed to N points. It isn’t a compliance product — it records planning decisions, nothing more — but when a PMO or a reviewer asks how a commitment was set, a documented rationale beats a reconstructed one every time.
A practical next step: before your next planning session, run the five guard-rails on one upcoming sprint. If the number they produce differs from what the team “feels,” you’ve just measured your overcommitment margin.
FAQ
How much should a government agile team commit to in a sprint? Multiply available person-days by your demonstrated points-per-person-day rate, and stay at or below your median velocity. When gut feel and the math disagree, the math wins.
What should we do with work that didn’t finish in an overcommitted sprint? Return it to the backlog and re-estimate it; don’t roll it forward automatically. Count only completed work in velocity so your planning data stays clean.
How do we explain a smaller commitment to leadership? Show the subtraction: 80 nominal person-days, 54 real, 0.53 points per day, 29 points. A documented capacity calculation reads as discipline, not slowness — and by the third predictable sprint, it reads as competence.
Try it: Install free on the Atlassian Marketplace · Help docs
Leave a Reply
Your email is safe with us.