A reliable government sprint planning checklist covers five checks: confirm the real roster and allocation, subtract holidays, leave, and training from the calendar, convert what’s left into a capacity number using past velocity, verify the backlog is sprint-ready, and record the commitment math. Run the checks on a countdown that starts five days before planning — not in the meeting itself.

Pilots run the same walk-around before every flight, no matter how many times they’ve flown the aircraft. Sprint planning deserves the same discipline, and in government it rarely gets it. A scrum master at a state agency walks into planning believing she has eight people; by Wednesday of week one, two are answering an audit data call, one is at mandatory training, and a state holiday has taken a day from everyone. The sprint was lost before it started — not to bad engineering, but to unchecked assumptions.

This discipline matters more now, not less. Many agencies are running with smaller teams than a year ago — hiring freezes and workforce reductions have thinned benches without shrinking missions. When a team of twelve loses a person for a week, that’s about 8 percent of capacity; when a team of six does, it’s 17. The smaller the team, the more expensive every unverified assumption becomes.

Why government sprints fail at planning, not at execution

Most missed sprint commitments in public-sector teams trace back to the planning meeting, not the two weeks that followed. The work was fine; the plan was fiction. Government teams carry constraints most private-sector teams don’t: holidays that cluster around fiscal milestones, mandatory training with hard completion deadlines, detail assignments and audit surges that claim people mid-sprint, and matrixed staff split across programs. None of these are surprises — they are all knowable in advance, which is what makes an unchecked plan an unforced error.

And in an agency, a missed commitment isn’t a private retrospective topic. It’s a milestone slip that travels up a reporting chain, sometimes all the way to an oversight question.

What should a scrum master check before sprint planning?

Five checks, on a countdown:

1. Confirm the roster and real allocation (five days out). Ask supervisors directly rather than relying on the org chart: is anyone detailed to another program, assigned to an audit or data-call response, or splitting time across teams? Record a percentage for each person. “Mostly on this team” is not a number.
2. Subtract the calendar (two days out). Pull federal and state holidays, approved leave, mandatory training blocks, and all-hands events into one view. In government these cluster — a holiday plus an end-of-quarter training requirement can quietly remove a fifth of a sprint before any work is assigned.
3. Convert what’s left into a number (two days out). Total the remaining person-days, then translate them into story points using the ratio from your last three completed sprints. This is the ceiling for the commitment — write it down before the meeting so it can’t be negotiated upward in the room.
4. Verify the backlog is sprint-ready (one day out). The top of the backlog should be estimated, have acceptance criteria, and carry no unresolved external dependencies — a story waiting on a security review or another team’s API isn’t ready, it’s a wish. Nothing should be larger than three or four days of work; split anything bigger.
5. Commit against the number and record the math (planning day). Capacity is a ceiling, not a target; take stretch items only if they’re marked as such. Then write down who was available at what allocation, what the calendar subtracted, which velocity you used, and why the team committed to N points. That one paragraph answers most of the questions leadership will ask in week two — without a meeting.

How do you calculate sprint capacity for a government team?

Take an eight-person team at a state health agency working on eligibility-system modernization, planning a two-week (ten working-day) sprint:

• Gross capacity: 8 people × 10 days = 80 person-days
• State holiday, everyone out one day: −8 → 72
• One developer on three days of approved leave: −3 → 69
• Mandatory half-day cybersecurity training for all eight: −4 → 65
• Two analysts at 50% on an audit data call (each has 8.5 days left after the holiday and training; half goes to the audit): −8.5 → 56.5 person-days net

The team’s last three sprints delivered 38, 41, and 41 points — an average of 40 — on a typical net capacity of about 64 person-days, or roughly 0.625 points per person-day. This sprint’s 56.5 person-days therefore supports about 35 points. The team commits to 34 with one clearly marked stretch item, instead of the 40 everyone “felt” they could do.

Making the checklist repeatable inside Jira

Run on a spreadsheet, this checklist survives about three sprints before it decays: the velocity figures go stale, the days-off tab drifts from the leave calendar, and the allocation percentages live in someone’s head. The fix is to run the checks where the backlog already lives. Sprint Planning with Capacity Planning for Jira puts past velocity, per-person days off, and allocation on one screen inside the Jira backlog, so the capacity number is computed — not estimated — before the team commits, and the plan itself becomes the record of what was subtracted and why. For agencies consolidating tooling as they move to Atlassian Cloud, the plan, the record, and the work end up in the same place. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

Want to test the checklist before your next sprint? Run it retroactively against your last completed one — if the number it produces is lower than what the team committed, you’ve found your overcommitment margin.

FAQ

What should a scrum master check before sprint planning? Five things: the real roster and each person’s allocation percentage, calendar subtractions (holidays, leave, training), a capacity number derived from past velocity, backlog readiness at the top of the queue, and a written record of the final commitment and the math behind it.

How far in advance should sprint capacity be calculated? Start five days out with roster and allocation, and finalize the number one to two days before planning. Morning-of is too late — allocation conflicts take days, not minutes, to resolve.

How is sprint capacity calculated? Multiply team size by working days, subtract holidays, leave, training, and partial allocations to get net person-days, then multiply by your points-per-person-day ratio from the last three completed sprints.

Try it: Install free on the Atlassian Marketplace · Help docs

admin

See Full Bio