A missed sprint in a startup costs a demo. A missed sprint in a government program can cost a fiscal-year deadline, a public commitment, or a line item in next year’s budget justification. That’s the uncomfortable truth behind agile in the public sector: the cost of overcommitting is higher, the room to recover is smaller, and the people you answer to are rarely in the room when the sprint is planned. This is exactly why capacity planning — not just sprint planning — deserves a front seat in government agile.

The public-sector reality that breaks naive sprint planning

Most agile training assumes a stable, full-time, co-located team. Government teams almost never look like that. A typical agency squad is some blend of full-time civil servants, contractors on specific task orders, detailees on loan from another office, and staff with mandatory obligations — training days, security refreshers, all-hands, committee work — that have nothing to do with the sprint but consume the same hours.

Plan a sprint on headcount alone and you will overcommit. Eight people on a board does not mean eight people’s worth of capacity. If two are part-time, one is on travel, and everyone loses a day to mandatory training, your “8-person sprint” is really closer to five. Velocity history won’t save you either, because last sprint’s velocity was measured under last sprint’s availability — which changes constantly in government settings.

Why the stakes are higher here

Three things make capacity discipline more important in government than in most commercial environments:

• Fixed budgets and fiscal-year boundaries. You can’t simply buy your way out of a capacity shortfall mid-year. The money is appropriated, the period of performance is set, and slipping work into “next quarter” may mean slipping it into next fiscal year.
• Accountability that flows upward and outward. Commitments often become part of a program plan briefed to leadership, oversight bodies, or the public. A sprint that quietly fails internally can become a visible miss externally.
• Trust is the currency. Long-tail agile adopters in government are often still proving that agile works. A few overcommitted, missed sprints can hand skeptics the argument that “agile doesn’t work here.” Predictability is how you keep the mandate.

What good capacity planning actually looks like

Aligning sprint planning with capacity planning isn’t a heavyweight process. It’s five concrete habits:

1. Start every planning session with availability, not stories. Before anyone pulls a ticket, establish how many working hours each person genuinely has this sprint after holidays, PTO, training, and other duties.
2. Translate availability into a capacity number. Convert hours (or a points-equivalent) into a single team capacity figure for the sprint. That number is your ceiling.
3. Compare against real past velocity. Use what the team actually delivered in comparable sprints — not its best sprint ever — as a sanity check.
4. Watch allocation per person. A team can be “at capacity” in aggregate while one developer is 140% allocated and another is at 60%. Over-allocation is where burnout and slips hide.
5. Plan future sprints’ capacity now. If you already know a key person is out for two weeks next month, reflect it in that sprint’s capacity today, so the forecast isn’t a surprise.

A quick worked example

Say a six-person team has a standard 80-hour-per-person sprint. On paper that’s 480 hours. But this sprint includes a federal holiday (−48 hours across the team), one detailee returning to their home office at 50% (−40 hours), and a mandatory all-staff training day (−48 hours). Real capacity is about 344 hours — roughly 72% of the headline number. A team that commits to 480 hours of work walks into the sprint already 28% over. A team that plans to 344 commits to what it can finish, hits it, and builds the track record that keeps leadership bought in.

Make it repeatable instead of heroic

The reason capacity planning often gets skipped isn’t that teams disagree with it — it’s that doing it in spreadsheets is tedious and goes stale the moment someone’s schedule changes. When velocity, planned capacity, individual days-off, and allocation all live on one screen inside the Jira backlog, the discipline stops being a separate chore and becomes part of how you plan. That’s the entire idea behind Sprint planning with Capacity Planning for Jira: adjust team and individual capacity per sprint, account for days off, and see allocation and past velocity in one view — before you commit.

Try it free: Install from the Atlassian Marketplace · Read the help docs.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio