Answer first: A sprint planning checklist for government scrum masters is a short, repeatable sequence — run before and during planning — that confirms three things before the team commits: a refined backlog, the team’s real capacity for this specific sprint, and one clear, testable sprint goal. Used every sprint, it stops teams from committing to last sprint’s velocity when half the team is detailed elsewhere, in training, or on leave.

Picture a scrum master on a state benefits-modernization program. The backlog looks ready, last sprint’s velocity was 38 points, so the team commits to 38. Three days in, two developers are pulled into a mandatory continuity-of-operations exercise, a third is finishing an oversight data request, and the sprint quietly slips. Nothing went wrong with the work. The commitment was wrong before the sprint began.

Why do government scrum masters need a planning checklist?

Agile teams everywhere overcommit, but public-sector teams carry disruptions that rarely show up in a commercial burndown: federal holidays, mandatory training, staff detailed to other programs, oversight and records requests, contracting actions that stall work, and — increasingly — flat budgets and workforce reductions. “Fewer people, same mission” is the operating reality for many agencies right now, and it makes one question sharper than ever: how much can this team actually deliver in the next two weeks?

A checklist is not bureaucracy. It is the cheapest way to make planning repeatable and honest, so a commitment reflects who is genuinely available — not who appears on the org chart. It also produces something government leaders increasingly ask for: a clear record of how the team arrived at its plan.

The pre-planning checklist: before everyone is in the room

Most failed sprints fail here, in the quiet work nobody sees. Before planning starts, confirm:

• The backlog is refined. The top items have acceptance criteria, are estimated, and are each small enough to finish inside one sprint.
• Dependencies are named. Flag anything that waits on another team, a contractor, a security or ATO review, or a contracting action.
• Capacity inputs are gathered. List who is on the team this sprint, their PTO and holidays, training days, detail assignments, and anyone allocated only part-time.
• Velocity is pulled. Use a rolling average of the last three sprints, not a single good one.
• A draft sprint goal exists. One sentence describing the outcome, not a list of tickets.

The in-planning checklist: in the room

With the prep done, planning itself gets short and disciplined:

1. State the single sprint goal and confirm the team agrees it matters.
2. Calculate available capacity: nominal days minus days off minus partial-allocation losses.
3. Convert that capacity into a realistic point target before looking at the backlog.
4. Pull items up to the target — and stop. Resist the round number.
5. Confirm each committed item has an owner and genuinely fits.
6. Name the top risk and a simple “if we lose someone” fallback.

How do you calculate sprint capacity in government? A worked example

Consider a five-developer team running a two-week (10 working day) sprint. On paper that is 50 developer-days. Now subtract this sprint’s reality:

• Developer A: 2 days of leave.
• Developer B: detailed to a security-review effort at 50% — 5 days gone.
• The whole team: 1 mandatory cybersecurity-awareness training day — 5 developer-days.
• Developer C: newly onboarded, ramping at half speed — 5 days.

That is 2 + 5 + 5 + 5 = 17 developer-days lost. Available capacity is 50 − 17 = 33 developer-days, or about 66% of nominal. If the team’s three-sprint average velocity is 36 points, the honest target is roughly 36 × 0.66 ≈ 24 points — not 36. Committing to 24 and delivering 24 builds the predictability government leaders trust. Committing to 36 and delivering 24 looks like failure, even though the team did solid work.

Make it repeatable inside Jira

A checklist works on paper, but it sticks when the inputs live where the work lives. Many agency teams are leaving scattered spreadsheets behind as part of the broader move to Atlassian Cloud — and Atlassian Government Cloud (AGC) — and that is the moment to stop juggling a separate capacity tab. Sprint planning with Capacity Planning for Jira puts past velocity, days-off, and allocation on one screen inside the Jira backlog, so you can see real capacity before you commit rather than discovering it mid-sprint. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. Just as useful for the chain of command: the plan now carries its own record — who was allocated, what days off were subtracted, and why the team committed to N points — the kind of documentation and decision trail that makes a planning process defensible when leadership or oversight asks how the number was set.

Turn the checklist into a habit

Want to make this real? Copy the three checklists above into your team’s “definition of ready,” then run the capacity math on your very next sprint — commit to the adjusted number, not the round one, and compare planned versus delivered at the retro. One sprint of honest capacity planning is usually enough to win over a skeptical team.

FAQ

What should a government scrum master do before sprint planning? Refine the top of the backlog, gather capacity inputs (PTO, holidays, training, details, part-time allocations), pull a three-sprint velocity average, and draft a one-sentence sprint goal. Walking in with these four things turns planning from a debate into a decision.

How long should sprint planning take? For a two-week sprint, aim for two hours or less. If planning routinely runs long, the cause is almost always unrefined backlog items or unclear capacity — both handled by the pre-planning checklist.

How do you plan when staff are cut mid-program? Recalculate capacity every sprint instead of trusting last quarter’s velocity. With fewer people, the gap between nominal and available capacity widens, so the discipline of subtracting days-off and partial allocations matters more, not less.

---

Try it: Install free · Help docs