Short answer: To deliver a fixed-deadline government program predictably, divide the remaining work by the sprints left, then test that required pace against the capacity you can actually staff after holidays, leave, training, and part-time allocation. If the required pace exceeds forecast capacity, you have a scope-or-schedule decision to make now, not a surprise in the final sprint.

The statute says go-live is the first week of March. The oversight committee has already been told. Then a hiring freeze removes one developer, two others get detailed to another program part-time, and the plan that looked fine in October is quietly impossible by December. “Fewer people, same mission” is the operating reality for many agencies right now, and it makes honest capacity math more important, not less.

Why do fixed deadlines break agile plans in government?

Agile assumes you can flex scope or date. Many public-sector programs cannot flex the date: a statutory effective date, a grant period, a contract option year, or a fiscal-year boundary fixes it. That leaves scope and capacity as the only levers, and most teams only look at scope.

The usual failure is planning against nominal headcount. Seven people on the roster is not seven people of capacity. Federal holidays, scheduled leave, mandatory training, and split allocations all shrink the number, and they do so unevenly across the calendar.

How do you build predictable delivery against a fixed date?

Use this five-step framework. It takes about an hour to set up and a few minutes per sprint to maintain.

1. Fix the backlog baseline. Estimate the remaining must-have work in one unit (story points or hours) and record the date you did it. Keep nice-to-haves in a separate, clearly labeled tier.
2. Count the sprints left. Work backward from the deadline, reserving the final sprint (or two) for hardening, acceptance, and release. Those are not delivery sprints.
3. Compute the required pace. Must-have points divided by delivery sprints remaining. This is the number leadership is implicitly promising.
4. Forecast capacity per sprint. Start from person-days, subtract holidays, leave, and training, apply each person’s allocation, then convert to points using your recent points-per-person-day.
5. Compare and decide early. Required pace versus forecast capacity gives you the gap. Close it with a documented decision: cut scope, add capacity, or move the date through the proper channel.

What does the math look like in practice?

Take a benefits-intake modernization with a hard go-live in March. Twelve weeks remain after the hardening sprint is reserved, which is six two-week delivery sprints. Must-have backlog: 240 points.

• Required pace: 240 ÷ 6 = 40 points per sprint.
• Team: five full-time members plus two at 50%. Raw allocated time: 5 × 10 + 2 × 5 = 60 person-days per sprint.
• Next sprint includes the Columbus Day holiday (5 + 2 × 0.5 = 6 person-days), 6 days of approved leave, and 4 days of required training. Available: 60 − 6 − 6 − 4 = 44 person-days.
• Recent history: the last three sprints averaged 36 points on roughly 48 available person-days, or 0.75 points per person-day.
• Forecast: 44 × 0.75 = 33 points.

The gap is 7 points this sprint, roughly 42 points across six sprints if nothing changes. That is a concrete, defensible number to bring to the sponsor: “We can credibly deliver about 200 of the 240 must-have points. We need to defer about 40, add roughly one person’s worth of capacity, or revisit the date.” Raising it in October is a planning conversation. Raising it in February is an escalation.

How do you keep the forecast honest as conditions change?

Re-run the comparison every sprint, not once. Three habits help:

• Update the required pace whenever scope is added or removed, and record who approved the change.
• Re-enter new leave, detail assignments, and training dates as soon as they are known.
• Report required pace versus forecast capacity as a single trend line. Leadership does not need burndown mechanics; they need to see whether the lines are converging.

The side benefit is a decision trail. A record of who was allocated, what days-off were subtracted, and why the team committed to N points shows what was known at each decision point. That is useful documentation when someone later asks why scope was cut. It is a planning record, not a compliance program.

How does doing this inside Jira make it repeatable?

Most teams run this math in a spreadsheet beside Jira. The spreadsheet drifts from the backlog, one person owns the formulas, and the numbers are stale by the next planning session. Agencies moving to Atlassian Cloud, including Atlassian Government Cloud (AGC), have a natural opportunity to retire those side spreadsheets and plan where the work already lives.

Sprint planning with Capacity Planning for Jira puts sprint planning and team capacity on one screen inside the Jira backlog. It uses past velocity, days-off, and allocation to show how much the team can take on before you commit, so the capacity forecast in step 4 is a view you open rather than a workbook you rebuild. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

How early should we reserve hardening time before a fixed deadline?
Reserve at least the final sprint, and two for larger releases involving acceptance testing or sign-offs. Treat those sprints as zero-capacity for new features when computing required pace.

What if past velocity is unstable?
Use the average of the last three to five sprints and show a range rather than a single number. A forecast of 30 to 36 points is more honest, and more useful, than a false 36.

Do we need story points to do this?
No. Hours work too, as long as you use one unit consistently for both the backlog baseline and the capacity forecast.

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

Practical next step: list your deadline, delivery sprints remaining, and must-have points today, and compute the required pace. Then compare it to next sprint’s forecast capacity. That ten-minute check is your readiness test.