A healthy sprint in a public-sector program is one where the team committed to less than its measured capacity, delivered 85–100% of that commitment, absorbed less than about 10% unplanned scope, and can show on one screen why it committed to that number. Five metrics capture this: capacity utilization, commitment reliability, scope change rate, carryover age, and allocation concentration. Raw velocity is not one of them.

Most government PMO dashboards have the opposite problem of most commercial ones. They are not short on charts — they are short on charts anyone trusts. A program manager at a state permitting modernization effort put it plainly: her portfolio review deck had eleven burndown charts, and the first question from the deputy director was always the same one they could not answer — “so are we going to make the September date or not?” Burndown showed what happened. It did not show whether the team ever had a realistic chance.

Why government sprint metrics have to answer a different question

Commercial agile metrics are usually optimized to answer “are we getting faster?” Government metrics have to answer “can we defend this commitment?” The audience is different: a program office reporting into an appropriations cycle, an IV&V reviewer, a contracting officer’s representative, or a deputy CIO who has to brief a fixed fiscal-year milestone. They are not looking for a productivity score. They are looking for evidence that a number on a schedule was arrived at deliberately.

That distinction matters more this year than last. Workforce reductions and flat budgets across FedCiv, DoD, and State & Local mean many teams are running the same mission with fewer people. When staff shrink, the gap between nominal team size and real available capacity widens — and the cost of planning against the nominal number goes up, not down. Meanwhile the compliance climate rewards teams that can show what happened, who acted, what changed, and what evidence supports the decision. A disciplined sprint record is exactly that kind of artifact.

What are the five metrics of a healthy sprint?

Track these five. Report the first three upward; keep the last two for the team and the scrum master.

1. Capacity utilization — committed points ÷ capacity-adjusted forecast. Healthy range: 80–90%. Above 100% means the team is committing to work it has no room for. Consistently below 70% means the buffer is too fat or the forecast is stale.
2. Commitment reliability (say/do) — points completed ÷ points committed, averaged over a rolling three sprints. Healthy range: 85–100%. Single-sprint say/do is noisy; the rolling number is what leadership should see.
3. Scope change rate — points added after sprint day one ÷ points committed. Healthy: under 10%. This is the single most useful number for explaining a missed sprint to a non-technical stakeholder, because it separates “the team was slow” from “the work changed.”
4. Carryover age — how many sprints the oldest incomplete item has rolled. Anything past two sprints is not carryover, it is a blocked item wearing a disguise, and it should be pulled out and named.
5. Allocation concentration — the share of committed points assigned to the single most-loaded person. Above roughly 30% on a six-person team, the sprint has a single point of failure. One unplanned detail assignment or one sick week takes the whole commitment down.

What should you stop reporting to leadership?

• Raw velocity as a productivity measure. Velocity is a planning input, not a performance score. The moment it becomes a target, estimates inflate and the number stops being useful for forecasting.
• Individual velocity. It rewards hoarding work and punishes the people who unblock others.
• Burndown shape on its own. A clean diagonal line usually means someone groomed the chart. Pair it with scope change rate or leave it out.

A worked example

A six-person team on a state permitting modernization program, two-week sprint, ten working days.

• Baseline: 6 people × 10 days = 60 person-days
• One engineer detailed to an audit response: −5 days
• One engineer in required security training: −2 days
• One analyst on PTO: −3 days
• Two state holidays across the whole team: −12 days
• Subtotal available: 38 person-days
• Standing production-support reserve of 15%: −5.7 days
• Net capacity: 32 person-days

The rolling three-sprint average was 34 points delivered across an average of 40 available person-days — a throughput rate of 0.85 points per person-day. So the capacity-adjusted forecast is 32 × 0.85 = 27 points. Committing at 85% utilization gives a commitment of 23 points.

Left to instinct, this team would have committed to 34 — last sprint’s velocity — and missed by roughly a third, for reasons that had nothing to do with how hard anyone worked. Instead they committed 23, finished 22 (say/do 96%), and absorbed 2 points of urgent scope (8.7% change rate). The sprint was, by every measure above, healthy. More usefully: the program manager could explain the 23 in one sentence at the portfolio review.

Making it repeatable inside Jira

The arithmetic above is not hard. Doing it every two weeks, for six teams, in a spreadsheet that lives on someone’s desktop is what fails. The subtraction gets skipped, the holiday calendar goes stale, and the record of why the team committed to 23 disappears the moment the sprint closes.

This is the case for doing capacity planning in the same place the work lives — part of the broader move to Atlassian Cloud and Atlassian Government Cloud (AGC) that many agencies are already midway through. Sprint planning with Capacity Planning for Jira puts past velocity, days-off, and per-person allocation on one screen inside the Jira backlog, before you commit. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. It records planning decisions — who was allocated, what days-off were subtracted, why the team landed on N points — so the decision trail survives the sprint.

FAQ

What is a good say/do ratio for a government agile team?
85–100% on a rolling three-sprint average. Sustained results above 100% usually mean the team is under-committing; below 80% means the capacity forecast is not being applied.

Should we report velocity to leadership at all?
Report it as context for the forecast, never as a performance number. The metric leadership actually needs is commitment reliability, which tells them whether dates from this team can be believed.

How many sprints of history do we need before these metrics mean anything?
Three completed sprints gives a usable throughput rate. Before that, plan on capacity alone and treat the first commitments as deliberately conservative.

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

A practical next step: pick one team and score its last three sprints against the five metrics above. If capacity utilization was over 100% in two of three, you have found your predictability problem — and you have the evidence to explain it upward.