The fastest way to miss a government deadline is to commit to more work than your team can actually do. Overcommitment happens when a sprint plan is built on the team’s headcount instead of its real, available capacity, and the cost shows up later as slipped milestones, eroded stakeholder trust, and a delivery record that’s hard to defend up the chain. The fix is straightforward: subtract reality from your plan before you commit, not after.
Why optimistic sprint planning quietly wrecks public-sector delivery
Picture a State health-agency team three sprints from a fiscal-year reporting deadline. On paper they have six developers, so the scrum master pulls in roughly six developers’ worth of work. But one engineer is detailed to a separate modernization effort two days a week, two people have approved leave, and a federal holiday lands mid-sprint. The plan assumed 100% availability; the team had closer to 65%. The sprint "fails" — but it never had a chance.
In government, this pattern is more expensive than in most commercial settings. Budgets are fixed, fiscal-year and contract boundaries are immovable, and a missed sprint often can’t be absorbed by simply spending more. With workforce reductions now common across FedCiv, DoD, and State & Local, the "fewer people, same mission" reality means the gap between headcount and real capacity is wider than ever. When staff are cut, knowing your true capacity before you commit matters more, not less. Chronic overcommitment also damages something harder to rebuild than a schedule: the credibility of your delivery forecasts when leadership asks, "Will it be done on time?"
How do you avoid overcommitting in a sprint?
Avoiding overcommitment is a discipline, not a personality trait. Four steps make it repeatable.
- Start from real capacity, not headcount. Convert your team to available person-days for the specific sprint. Begin with working days, then subtract approved leave, training, holidays, and any partial allocation to other programs. The number you get is almost always lower than "team size times sprint length" — and that lower number is the truth.
- Anchor your commitment to demonstrated velocity. Look at the average points (or items) your team actually completed over the last three to five sprints, not its best-ever sprint. Optimism creeps in when teams plan against their peak. Plan against your median.
- Adjust velocity for this sprint’s available capacity. If your reference velocity was earned at near-full capacity and this sprint runs at 70%, scale the commitment down proportionally. This single adjustment prevents most overcommitment.
- Hold a buffer and name it. Reserve 10–20% for the unplanned work that always arrives — an urgent data call, a security patch, a leadership request. A buffer isn’t slack; it’s the line item that keeps your committed work actually deliverable.
A worked example: from headcount to a defensible commitment
A five-person FedCiv team runs a two-week sprint (10 working days). Naively, that’s 50 person-days. Now subtract reality:
- One federal holiday: −5 person-days (everyone off one day)
- One engineer on approved leave for 3 days: −3 person-days
- One engineer detailed to another program at 40%: −4 person-days over the sprint
- Ceremonies, email, and standing meetings at ~15%: −about 5.7 person-days
Real available capacity ≈ 50 − 5 − 3 − 4 − 5.7 = 32.3 person-days, roughly 65% of the headcount figure. If the team’s demonstrated velocity is 40 points at full capacity, the capacity-adjusted target is about 40 × 0.65 ≈ 26 points. Apply a 15% buffer and you commit to roughly 22 points. The team that commits to 22 finishes and reports a clean sprint; the team that commits to 40 because "we have five people" misses by nearly half — and has to explain why.
Why doing this in one screen inside Jira makes it stick
The math above is simple, but it’s tedious to maintain in a side spreadsheet that drifts out of date the moment leave changes or someone gets detailed elsewhere. That’s why agencies modernizing on Atlassian Cloud — including teams migrating to Atlassian Government Cloud (AGC) — increasingly want this calculation living where the work lives. Sprint planning with Capacity Planning for Jira puts past velocity, days-off, and per-person allocation on one screen inside the Jira backlog, so you can see real capacity and adjust your commitment before you commit, not after the sprint fails. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.
There’s a second benefit that matters in government: doing it in one tool creates a record. Each plan captures who was allocated, which days-off were subtracted, and why the team committed to N points. When a PMO or oversight reviewer later asks how a commitment was set, you have a clear decision trail instead of a reconstructed guess. The app records planning decisions — it isn’t a compliance product and provides no certification — but a documented, repeatable rationale is exactly the kind of evidence that disciplined delivery organizations are now expected to produce.
FAQ
What’s the difference between velocity and capacity? Velocity is how much work your team has historically completed; capacity is how much working time the team actually has available in the upcoming sprint after leave, holidays, and other allocations. Overcommitment usually comes from using full velocity while ignoring reduced capacity.
How big should a sprint buffer be? A common starting point is 10–20% of available capacity, then tune it to how much unplanned work your team typically absorbs. Teams with frequent urgent data calls or security work should lean toward the higher end.
Isn’t planning conservatively just lowering the bar? No — it’s making your commitments true. A team that reliably delivers what it promised builds far more credibility with leadership than one that promises big and misses, even if the "smaller" plan looks less ambitious on paper.
Try it: Install free · Help docs
Leave a Reply
Your email is safe with us.