Short answer: A 12-month agile maturity roadmap for a government team works best as four quarterly stages (stabilize, measure, forecast, scale), each unlocked by a planning habit rather than a calendar date. The habit that matters most is knowing real capacity before the team commits to a sprint.

“Fewer people, same mission” is now the planning reality for many agencies. Headcount is flat or shrinking, the fiscal-year deadline has not moved, and leadership still expects agile to show results. Maturity in that setting does not mean more ceremonies. It means commitments that hold up.

Why do government agile roadmaps stall?

Most stalled adoptions share one pattern: the roadmap is built around training and tooling milestones, while the sprint-level numbers stay informal. Teams commit based on the last sprint’s feel, absences surface mid-sprint, and the first missed commitment becomes the reason sponsors lose patience.

A roadmap that ties each stage to a measurable planning behavior avoids this. Sponsors can see progress as evidence, not as attendance at workshops.

What does a 12-month maturity roadmap look like?

1. Months 1–3: Stabilize. Fix the sprint length, keep one backlog, and write down who is on the team and at what allocation. Start recording days-off for every sprint, including federal holidays, leave, training, and time detailed to other programs. Goal: every sprint has a written capacity figure before planning starts.
2. Months 4–6: Measure. Track completed points per sprint next to available person-days. After three sprints you have a usable ratio of output per available day. Goal: the team can explain every gap between planned and delivered work.
3. Months 7–9: Forecast. Use that ratio to project the next quarter, with a range instead of a single date. Goal: leadership receives a forecast that states its assumptions, such as expected leave and staffing changes.
4. Months 10–12: Scale. Add a second team or program only after the first can forecast within a tolerable margin. Goal: shared planning conventions, so reports from different teams are comparable.

How do you calculate capacity at each stage?

Use the same four-step calculation from the first sprint to the last. Only the quality of the inputs improves.

• Start with gross person-days: team members multiplied by working days in the sprint.
• Subtract holidays, leave, and training days.
• Subtract the share of time people are allocated to other programs.
• Multiply the remaining person-days by your measured points-per-day ratio from recent sprints.

Worked example: an eight-person team in month 7

The team runs 10-day sprints. Gross capacity is 8 × 10 = 80 person-days. This sprint contains one federal holiday (8 person-days), 5 days of approved leave, and 2 days of mandatory training. Two team members are allocated 50% to another program (2 × 10 × 0.5 = 10 person-days).

Available capacity: 80 − 8 − 5 − 2 − 10 = 55 person-days.

Over the last three sprints the team averaged 33 points on 58 available person-days, about 0.57 points per day. Forecast for this sprint: 55 × 0.57 ≈ 31 points. A team committing to its previous 33 would be roughly two points over what the calendar supports. The gap is small, but repeated across a quarter it is how a fiscal-year milestone slips unnoticed.

Why does this create a defensible record?

Agencies increasingly want to show what happened, who acted, what changed, and what evidence supported a decision. Sprint planning is a small part of that picture, but a useful one: a recorded capacity figure shows who was allocated, which days-off were subtracted, and why the team committed to N points. This is documentation of planning decisions. It is not a compliance program, and it does not replace one.

How does doing this inside Jira make it repeatable?

Spreadsheets work for one team in one quarter. They break when allocation changes, a second team joins, or the person who built the workbook moves on. Keeping the calculation in the Jira backlog, where the work already lives, removes the copy-and-paste step. For agencies moving to Atlassian Cloud, including Atlassian Government Cloud (AGC), it also keeps planning on the same platform as the issues.

Sprint planning with Capacity Planning for Jira shows sprint and team capacity on one screen, using past velocity, days-off, and allocation, before you commit. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. Divim itself does not hold those certifications.

A 90-day starter plan

If you only do one thing this quarter, run the first stage: list your team and allocations, record days-off for the next six sprints, and write a capacity figure on the board before each planning meeting. By day 90 you will have three data points for the measure stage.

FAQ

How long does it take a government team to reach predictable delivery?

It varies by team, but a practical target is three to four completed sprints with recorded capacity before trusting a points-per-day ratio, then a quarter of forecasting before sharing ranges with leadership.

Should we scale to multiple teams before the first team is stable?

No. Add teams once the first can forecast within a margin your sponsors accept; otherwise you multiply unpredictability.

What if staffing changes mid-roadmap?

Update allocations and recalculate. Because capacity is built from person-days, a reduction shows up directly in the forecast instead of as a surprise at sprint review.

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