Scaling agile maturity in a government organization takes about 12 months and follows a predictable path: stabilize one team’s sprint cadence, make commitments capacity-based instead of optimistic, extend the discipline to sibling teams, then use the accumulated velocity record to forecast quarters and report predictability up the chain. This article lays out that roadmap quarter by quarter, with a worked example you can adapt.

The pressure to get there is real. Across FedCiv, DoD, and State & Local, teams are being asked to deliver the same mission with fewer people and flat budgets. When staff are cut, guessing at what a team can absorb stops being a harmless habit — every overcommitted sprint burns hours you no longer have. Agile maturity, in this climate, is less about ceremonies and more about one question: can you say what you’ll deliver and then deliver it?

Why does agile maturity stall in government?

Most agency teams get stuck at the same plateau: they run sprints, hold standups, and use Jira, but commitments are still negotiated by gut feel. Three forces cause it. First, staffing is fluid — details, part-time allocations, and contract turnover mean the team that finishes a sprint is rarely the team that started the quarter. Second, the calendar is hostile: federal holidays, mandatory training, and fiscal-year crunches carve unpredictable holes in capacity. Third, nobody writes down why a commitment was made, so there is nothing to learn from when a sprint fails. Maturity is what you build when you fix all three deliberately, in sequence.

What does a 12-month agile maturity roadmap look like?

Months 1–3: Stabilize one team

Pick a single team and hold the sprint length fixed. Do not chase velocity — just record it honestly for four to five sprints, along with the say-do ratio (points delivered ÷ points committed). Resist the urge to fix everything; the only goal this quarter is an honest baseline. Most government teams discover their say-do ratio sits between 55% and 70%, which feels embarrassing and is in fact the most useful number they own.

Months 4–6: Make commitments capacity-based

Now change how commitment happens. Before each planning session, calculate real capacity: person-days available after holidays, leave, training, and partial allocations, expressed as a percentage of a full sprint. Multiply rolling velocity by that percentage and treat the result as the ceiling. Write down the inputs — who was allocated at what percentage, which days were subtracted, and why the team committed to N points. That record is what turns planning from opinion into evidence, and it is exactly the kind of decision trail leadership and oversight bodies increasingly expect: who acted, what changed, and what supported the decision.

Months 7–9: Extend to sibling teams

With one team predictable, replicate the practice rather than the people. Give each new team the same three artifacts: a fixed cadence, a capacity worksheet, and a commitment record. Where staff are shared across teams — the usual government reality — make allocation explicit: a developer split 60/40 across two programs is 60% capacity on one plan and 40% on the other, never 100% on both. Over-allocation hides here, and this is the quarter you flush it out.

Months 10–12: Forecast and report up the chain

By now each team has two quarters of honest velocity. Use it to forecast: multiply average velocity by sprints remaining in the quarter, adjusted for known capacity dents, and give leadership a range instead of a promise. Report say-do ratio and velocity trend monthly. This is the quarter agile stops being a team habit and becomes something a PMO can defend in a budget review.

A worked example: one team’s second quarter

A state revenue-modernization team enters month 5 with a rolling velocity of 36 points and a baseline say-do ratio of 62%. The next 10-day sprint contains Labor Day, one developer with three days of mandated training, and a database specialist allocated at 50%.

• Five full-time developers: 5 × 10 = 50 days, minus 5 holiday days, minus 3 training days = 42 days
• Database specialist at 50%: 5 days, minus 0.5 holiday = 4.5 days
• Available: 46.5 of a nominal 60 person-days = 77.5% capacity

Capacity-based commitment: 36 × 0.775 ≈ 28 points. The team commits 28, delivers 27 — a 96% say-do ratio, up from 62%, with nothing changed except arithmetic and honesty. Three sprints of that record is what makes the month 10–12 forecasting quarter possible.

How one screen in Jira makes the roadmap repeatable

Every step above can be run on spreadsheets, and that is where most agencies start — and stall, because the spreadsheet lives outside Jira, goes stale, and dies when its owner rotates out. As agencies modernize onto Atlassian Cloud (or Atlassian Government Cloud), it makes sense to move the capacity math into the backlog itself. Sprint Planning with Capacity Planning for Jira puts past velocity, days-off, and per-person allocation on one screen next to the sprint you are about to commit — so the months 4–6 practice becomes the default way planning happens, for every team you add in months 7–9, and the planning record accumulates where auditors and leadership can see it. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform.

FAQ

How long until a government team has a usable velocity baseline?
Four to five fixed-length sprints — roughly one quarter. Shorter samples swing too much with holidays and staffing changes to forecast from.

Do we need SAFe or another scaling framework to be “mature”?
No. Maturity here means predictable, evidence-based delivery. Some large agencies layer a scaling framework on top later, but capacity-based commitment per team is the prerequisite either way.

What should a PMO measure across the 12 months?
Three numbers per team: say-do ratio, rolling velocity trend, and planned capacity versus actual. Together they show whether predictability is improving without inviting velocity-inflation games.

Try it: Install Sprint Planning with Capacity Planning for Jira free · Help docs