Answer: A government-ready sprint planning checklist has five non-negotiable checks before a team commits: confirmed net capacity (days-off and training subtracted from raw hours), a backlog groomed and estimated ahead of the meeting, a sprint goal tied to a program milestone, a look-back at last sprint’s planned-vs-actual points, and a documented allocation snapshot leadership can review after the fact. Skip any one of these and public-sector sprints tend to fail the same way: quietly, and usually right before a status briefing.

Picture a scrum master at a state licensing agency, two sprints into modernizing an online renewal portal. The team lost a developer to a hiring freeze backfill three sprints ago and nobody adjusted the planning math. Sprint after sprint, the team commits to the same story-point total it always has, misses it by 20-30%, and the scrum master spends Monday morning explaining the gap to a PMO director who wants to know why “agile” isn’t making delivery more predictable. The problem isn’t the team’s effort. It’s that sprint planning never accounted for who was actually available.

Why government sprint planning breaks differently

In the private sector, an optimistic sprint is a minor embarrassment. In government, it’s a data point in a report that goes up a chain — to a PMO, an IG audit, an appropriations committee. Agencies across FedCiv, DoD, and State & Local are running fewer people against the same mission right now, which means the old habit of “commit to what we usually commit to” breaks faster than it used to. A checklist doesn’t fix understaffing, but it does stop a scrum master from re-promising capacity the team no longer has.

The pre-sprint-planning checklist

Run through these five checks before the team walks into the planning meeting, not during it:

1. Net capacity, not raw headcount. Start from each person’s available days in the sprint, subtract PTO, training, details to other programs, and standing meeting load, then convert to points or hours using the team’s own historical throughput — not a generic “6 productive hours a day” assumption.
2. A backlog that’s actually ready. Every candidate story has acceptance criteria, a rough estimate, and no open dependency on a ticket still in another team’s backlog. Refinement happens before planning, not during it.
3. A sprint goal in plain language. One sentence a program manager could repeat in a briefing without translation — “ship the renewal fee calculator for review,” not “close 34 points.”
4. A look-back at the last sprint. Compare committed points to completed points and ask why, specifically, if they diverge — a bad estimate, a mid-sprint scope change, or capacity that was wrong going in. Feed that answer into this sprint’s numbers.
5. A written record of the allocation decision. Who was planned at what percentage, what days-off were subtracted, and what the team committed to as a result. This isn’t extra paperwork — it’s the difference between “trust us” and being able to show, a year later, exactly why the team took on what it took on.

How do you calculate sprint capacity in government?

Take the same math you’d use anywhere and be stricter about the deductions, because government calendars have more of them. Start with each team member’s working days in the sprint, subtract federal holidays, approved leave, mandatory training, and any percentage they’re detailed to another program, then multiply the remaining days by that person’s average points-per-day from the last three to five sprints — not a team-wide average, since a detailed-away senior developer and a newly onboarded junior contractor don’t produce the same rate.

A worked example

A five-person team is planning a two-week (10 working-day) sprint. One developer is on approved leave for 3 days. Another is spending 20% of the sprint in mandatory records-retention training. A third is detailed to a separate reporting-deadline effort at 30% for the whole sprint. Raw capacity looks like 50 person-days. Net capacity, after subtracting leave (3 days), training (2 days), and the detail (3 days), comes out to 42 person-days — a 16% reduction the team would otherwise have planned right past. At the team’s historical rate of roughly 1.1 points per person-day, that’s about 46 points of real capacity, not the 55 points raw headcount would suggest. Planning to 55 is exactly how a team ends up explaining a 16% miss that was baked in before the sprint even started.

Doing this in one screen instead of three spreadsheets

Most of this checklist falls apart in practice not because scrum masters don’t know it, but because the inputs live in different places — a leave tracker, a training calendar, a velocity spreadsheet, and the Jira backlog itself. Sprint planning with Capacity Planning for Jira puts past velocity, days-off, and allocation on one screen inside the backlog, so the net-capacity math in step one and the allocation record in step five happen in the same place the team is already estimating and committing work — before the sprint starts, not reconstructed afterward for a briefing. As agencies move this kind of planning off spreadsheets and onto Atlassian Cloud — including Atlassian Government Cloud (AGC) for teams that need that environment — having capacity and commitment live next to the backlog is what makes the checklist repeatable instead of a one-time exercise.

FAQ

Does a sprint planning checklist replace estimation?
No. It sequences the inputs — capacity, backlog readiness, and last sprint’s actuals — so estimation happens against real numbers instead of assumptions carried over from a fuller-staffed sprint.

How often should the checklist be updated?
Review it every sprint, since leave, training, and details change constantly in government teams; a capacity number that was accurate two sprints ago rarely still is.

Is this only for teams new to agile?
No — mature teams miss this too, usually because capacity tracking lived in a side spreadsheet that stopped getting updated once the sprint cadence felt routine.

Try it: Install free · Help docs