Short answer: A government team can move from “running sprints” to genuinely predictable delivery in about four quarters — spend the first quarter only measuring, the second making capacity explicit before every commitment, the third making the planning record legible to leadership, and the fourth extending the practice across teams and onto the fiscal calendar. Agile maturity in the public sector is not a framework rollout or a badge; it is the shrinking gap between what a team commits to and what it actually ships.

A program manager at a state transportation agency recently told her steering committee that the permitting-portal squad had “gone agile” eighteen months earlier. The committee’s next question was the one she could not answer: so what will be in production before the fiscal year closes? The team had stand-ups, a board, a groomed backlog, and a burndown chart. What it did not have was a number anyone could defend in a room full of people who had never attended a sprint review.

That gap — ceremonies adopted, predictability not — is where most public-sector agile adoptions stall. The fix is not more ceremony. It is a deliberate, sequenced 12-month climb.

What does “agile maturity” actually mean for a government team?

In commercial software, maturity often gets measured by practice adoption: pairing, CI/CD, trunk-based development. In an agency, the measure that matters to everyone above the team is narrower and harder: can you tell us what you will deliver, and were you right?

Government teams climb that curve under constraints commercial teams rarely face all at once:

• Hard calendar edges. Obligation deadlines and fiscal-year boundaries do not slide because a sprint slipped.
• Shared and rotating staff. People are detailed elsewhere, split across programs, or pulled into mandatory training mid-sprint.
• Fewer people, same mission. With workforce reductions and flat budgets across FedCiv, DoD, and State & Local, knowing real capacity before committing matters more, not less.
• Upward accountability. Someone will eventually ask why the team committed to what it committed to — and “the team felt good about it” is not an answer.
• Modernization running in parallel. Many teams are climbing this curve while migrating off Data Center and spreadsheets onto Atlassian Cloud or Atlassian Government Cloud (AGC), which is an opportunity: the new platform is where the planning record can finally live in one place.

Months 1–3: measure, change nothing

The first quarter is the one teams skip, and skipping it is why month twelve arrives with no evidence of progress. Resist the urge to reform anything. Instead:

1. Fix the sprint length and stop changing it. Two weeks is the default for a reason — you get 26 data points a year instead of 12.
2. Record committed vs. completed every sprint. Two integers. Nothing else. This is your baseline predictability series.
3. Start logging days off honestly. Leave, holidays, training, detail assignments, collateral duties. Do not estimate them — record them.
4. Write down the commitment rationale in one sentence at the end of each planning session: who was available, what was subtracted, why the number landed where it did.

By the end of month three you should have six sprints of paired data and an unflattering, useful picture. Most teams discover they have been delivering 60–75% of what they commit to, consistently.

Months 4–6: how do you make capacity explicit before you commit?

Now you act on the baseline. The rule for this quarter: no commitment is made before available capacity is calculated on screen and visible to everyone in the room.

The sequence is simple and should take under ten minutes:

• Start from raw capacity — people on the team × working days in the sprint.
• Subtract known days off: holidays, approved leave, scheduled training, and the fraction of each person detailed to other work.
• Convert trailing velocity into a rate per available person-day, rather than treating velocity as a flat number.
• Apply that rate to this sprint’s available days to get a defensible commitment ceiling.
• Commit at or below the ceiling. Log the difference if you go under, and why.

The cultural change this quarter is that “we can probably squeeze it in” stops being an acceptable input. The number replaces the vibe.

Months 7–9: make the record legible upward

By month seven the team is planning well. Nobody outside the team knows it yet. This quarter is about translation.

Build a one-page rolling view that shows, per sprint: available capacity, committed points, completed points, and the variance. Add a simple trailing predictability percentage. Bring that single page to every steering committee and program review — the same page, every time. Consistency is what earns trust; a new chart each month reads as a team looking for a flattering angle.

This is also where disciplined planning starts paying a second dividend. Buyers across the public sector are under real pressure to prove what happened, who acted, what changed, and what evidence supports the decision. A sprint-by-sprint record of who was allocated, what days off were subtracted, and why the team committed to N points is exactly that kind of decision trail — not a compliance product, but a documented rationale that survives staff turnover and audit-style questioning.

Months 10–12: scale across teams and onto the fiscal calendar

The last quarter extends the practice outward:

• Standardize the inputs across squads — same sprint length, same days-off categories, same definition of “available.” Without this, cross-team roll-ups are fiction.
• Surface cross-team allocation. The shared database engineer counted at 100% by three teams is the single most common source of program-level slippage.
• Forecast to the fiscal boundary. Count the remaining sprints before the FY close, apply the trailing rate, and produce a range — not a date.
• Run a maturity checkpoint. Compare month-12 predictability against the month-3 baseline. That delta is your evidence the investment worked.

A worked example: one squad at the month-nine checkpoint

A six-person squad on a state DOT permitting portal runs two-week sprints — 10 working days.

• Raw capacity: 6 people × 10 days = 60 person-days
• One federal holiday, whole team: −6 days
• Approved leave, one engineer: −4 days
• Mandatory security training, one engineer: −2 days
• One engineer detailed 40% to a separate modernization effort: −4 days
• Available capacity: 44 person-days (73% of raw)

Trailing three sprints delivered an average of 32 points against an average of 48 available person-days — a rate of 0.67 points per available person-day. Applied to this sprint: 44 × 0.67 = 29.3.

So the squad commits to 29 points, not the 32 its “velocity” suggests. Before month four, this team would have taken 32, delivered 24, and spent the retro explaining itself. The three points it gave up were never real.

Why this is easier in one screen inside Jira

Every step above is doable in a spreadsheet, and that is precisely why maturity programs decay: the person maintaining the workbook rotates off, and the practice leaves with them. The climb sticks when the calculation lives where the work lives.

Sprint planning with Capacity Planning for Jira puts past velocity, days off, and per-person allocation on one screen inside the Jira backlog, so the capacity number is calculated before the commitment is made rather than reconstructed afterward. It is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform — which matters when an agency is consolidating planning onto Atlassian Cloud or AGC and does not want a parallel workbook living on someone’s desktop.

FAQ

How long does it really take a government team to become predictable?
Most teams see a measurable improvement in the committed-vs-completed gap by month six, and a defensible trailing predictability figure by month nine. Twelve months is the realistic horizon for making it stick across multiple squads.

What is the single best metric to track for agile maturity in the public sector?
Trailing predictability — completed points divided by committed points, averaged over the last six sprints. It is one number, it is hard to game, and non-technical leadership understands it immediately.

Can a team do this while it is still migrating to Atlassian Cloud?
Yes, and the migration is a good forcing function. Standardizing sprint length, days-off categories, and allocation definitions is easier during a platform move than after everyone has settled into new habits.

Start with a 90-day block

Do not try to buy the whole twelve months at once. Commit to months 1–3 only: fix your sprint length, log committed vs. completed, record days off honestly, and write one sentence of rationale per planning session. If the baseline does not tell you something uncomfortable, you have not measured it correctly — and if it does, you now have the case for everything that follows.

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