Short answer: a healthy sprint is one where the team commits to roughly what its real capacity supports, finishes most of it, and absorbs little unplanned work. Government PMOs can judge that with five numbers: commitment reliability, capacity utilization, velocity range, carryover rate, and mid-sprint scope change.

Your oversight office asks a fair question every month: “Is this team on track?” Too often the answer is a burndown chart that looks fine until the last two days, when half the stories turn out to be unfinished. With fewer people expected to deliver the same mission, a sprint that quietly misses is expensive. Here is a short set of metrics that tells you early.

Why do government PMOs need sprint health metrics?

Public-sector programs answer to fixed budgets, fiscal-year deadlines, and several layers of review. A team that “feels busy” is not evidence. Leaders increasingly want to see what was planned, who was available, what changed, and why a commitment was made. Sprint health metrics turn a vague status into a repeatable record, and they surface trouble in sprint three rather than sprint nine.

They also protect teams. When budgets are flat or headcount drops, pressure to “just take on more” rises. Numbers based on real availability give a scrum master something concrete to point to.

Which five metrics show whether a sprint is healthy?

1. Commitment reliability. Points completed divided by points committed at sprint start. Teams in a healthy rhythm tend to land in the high 80s to mid 90s percent; a steady 100% can mean the team is sandbagging, and a swing between 50% and 110% means planning is guesswork.
2. Capacity utilization. Person-days actually planned divided by person-days truly available after holidays, leave, training, and part-time allocation. Plan against the available figure, not the nominal headcount.
3. Velocity range. Look at the last three to five sprints and track the spread, not just the average. A tight range is what makes a forecast defensible.
4. Carryover rate. The share of committed items that roll into the next sprint. A single sprint of high carryover is noise; three in a row is a planning problem.
5. Mid-sprint scope change. Points added or removed after the sprint started. Some change is normal in government work, but it should be visible and explained.

Resist the urge to add ten more. Five metrics that every stakeholder understands beat twenty that nobody reads.

How do you calculate the capacity behind the metrics?

Most of these metrics depend on one input people skip: real available capacity. A repeatable method:

• Start with working days in the sprint for each person.
• Subtract federal holidays, approved leave, training, and recurring obligations outside the team.
• Multiply by the person’s allocation to this team (a 50% detailee counts half).
• Divide historical velocity by historical available person-days to get points per person-day, then apply it to the coming sprint.

What does a worked example look like?

Take a six-person team on a 10-day sprint, all fully allocated. Nominal capacity is 60 person-days. This sprint includes one federal holiday (6 person-days lost), 5 days of approved leave, and 2 days of mandatory training, so 13 days are removed. Available capacity is 47 person-days, or about 78% of nominal.

The last three sprints delivered 34, 38, and 36 points on an average of 52 available person-days, which is about 0.69 points per person-day. Applying that to this sprint: 47 × 0.69 ≈ 32 points. The sensible commitment is 32, not the usual 36.

Suppose the team finishes 30 of 32. Commitment reliability is 94%, carryover is one small story, and the PMO has a clear record: why 32, who was away, and what moved. Had the team committed 36 by habit, the same result would read as 83% and spark an avoidable conversation about performance.

How do you present this to leadership?

Lead with the plain-language result: “The team committed to 32 points based on 47 available person-days and delivered 30.” Then show the five numbers as a trend across the last several sprints. Agencies moving workloads toward Atlassian Cloud, including Atlassian Government Cloud (AGC), often find this is the moment when reporting stops living in a side spreadsheet and starts living where the work is. A consistent record of who was allocated, what days off were subtracted, and why the team committed to N points also supports the documentation habits reviewers increasingly expect, though it is a planning record, not a compliance product.

How does doing this in one tool inside Jira make it repeatable?

The hard part is not the arithmetic; it is doing it identically every sprint. When capacity lives in one spreadsheet, velocity in another, and leave in a calendar, the numbers drift. Sprint planning with Capacity Planning for Jira puts sprint planning and team capacity on one screen inside the Jira backlog, 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. Setup and usage are covered in the help docs.

A practical start: pick one team, record the five metrics for the next three sprints, and review them at the retrospective. That is a 90-day pilot most PMOs can run without a procurement cycle.

FAQ

What is a good commitment reliability for a government agile team?
Roughly 85-95% over several sprints is a reasonable healthy band. Consistency matters more than any single number.

Should we compare velocity across teams?
No. Points are relative to each team’s own estimating scale. Compare each team to its own trend instead.

How many sprints of history do we need?
Three to five completed sprints give a usable velocity range. Fewer than that, label forecasts as provisional.

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