Velocity is a trailing average of what your team delivered in past sprints. Capacity is what the people actually available in the next sprint can deliver. Government teams get it wrong when they commit to the trailing average after the roster that earned it has changed — and in a year of hiring freezes and workforce reductions, it changes constantly.

Look at almost any agency Jira instance right now and you’ll find a velocity chart describing a team that no longer exists. The chart says 45 points. But two of the eight seats behind that number are frozen, one engineer is on detail to an incident-response task force, and there’s a state holiday in the middle of the sprint. The chart isn’t wrong about the past — it’s silent about the present. “Fewer people, same mission” is the operating reality across FedCiv, DoD, and state and local government, which makes the velocity-versus-capacity distinction the most practical one in public-sector agile.

This is Part 2 of our velocity-vs-capacity series for public-sector teams. Part 1 covers the core distinction and the baseline framework; this installment covers resetting your sprint commitment when the roster changes. More availability-first methods: the Jira capacity planning hub.

What is the difference between velocity and capacity in agile?

Velocity answers “how much did this team finish per sprint, on average?” It is measured, not estimated — a rate derived from history. Capacity answers “how many productive person-days does the upcoming sprint actually contain?” It is calculated from the calendar: who is on the roster, their allocation percentages, planned leave, holidays, and training.

The subtlety most teams miss: velocity is a property of a specific group of people working a specific rhythm. Capacity is a property of the next two weeks. Planning needs both — velocity converts backlog items into a rate of delivery, and capacity tells you how much of that rate you will actually have this time.

What do government teams get wrong about velocity?

They treat velocity as a commitment. The chart says 45, so the team commits 45. That turns an average into a quota — and an average, by definition, includes the team’s best sprints. Committing to it means planning to hit a good sprint every sprint.

They let velocity outlive the roster that earned it. Velocity belongs to a roster, not to a team name in Jira. After a hiring freeze, a detail, or a reduction, the trailing average is describing people who are no longer in the room. This is the costliest mistake of the current budget climate: when staff shrink, teams need their numbers to be more honest, not less.

They report velocity up the chain as a performance metric. Once leadership reads rising velocity as “good” and falling velocity as “a problem,” teams quietly inflate estimates and the number stops meaning anything. Velocity is a planning input. The metric worth reporting upward is predictability — planned versus delivered.

They count heads instead of availability. A “six-person team” with a 50% matrixed analyst, a part-time contractor, and mandatory training on the calendar is not six people’s worth of days. Headcount flatters; person-days tell the truth.

How do you set a sprint commitment using both?

1. Re-baseline velocity when the roster changes. Average the last three to five sprints delivered by the current roster. If more than roughly 15% of your person-days have changed hands, treat older sprints as another team’s history.
2. Build an availability ledger for the upcoming sprint. For each person: working days in the sprint, minus holidays, minus approved leave, minus training, minus the share of their time allocated to other programs. This is a ten-minute exercise at the start of planning — and it’s the step teams skip.
3. Scale the commitment. Adjusted ceiling = trailing velocity × (this sprint’s person-days ÷ the average person-days behind that velocity). Pull backlog items up to the ceiling, then stop.
4. Write the reasoning down. Record who was available, what was subtracted, and why the team committed to N points. When an oversight body or steering committee asks why the commitment dropped this sprint, a dated planning record answers in one glance — memory doesn’t.

A worked example: fewer people, same mission

A state Medicaid modernization team averaged 45 points per sprint back when it had eight people and roughly 72 available person-days per two-week sprint. Two positions are now frozen, so six people remain. The upcoming 10-day sprint looks like this:

• Raw capacity: 6 people × 10 days = 60 person-days
• State holiday mid-sprint: −6 (one day × six people)
• One engineer reserved half-time for legislative audit data calls: −5
• Approved PTO: −3

That leaves 46 person-days, against the 72 that produced the 45-point average. The availability ratio is 46 ÷ 72 ≈ 0.64, so the honest ceiling is 45 × 0.64 ≈ 29 points — roughly a third less than the velocity chart implies. A team that commits to 29 and delivers 29 looks reliable. A team that commits to 45 and delivers 29 looks like it failed, even though both teams did identical work.

How do you make this repeatable inside Jira?

The ledger is easy in week one. It’s usually abandoned by sprint six, because it lives in a spreadsheet next to Jira rather than in it, and the one person who maintains it eventually takes leave too. The habit sticks when the inputs sit on the same screen as the decision. Sprint Planning with Capacity Planning for Jira puts past velocity, each person’s days off, and their allocation directly in the Jira backlog, next to the work you’re about to commit — so the adjusted ceiling is visible before you commit, not reconstructed after. For agencies consolidating onto Atlassian Cloud, it’s a Cloud Fortified app that runs on Atlassian’s SOC 2 Type II / ISO 27001 platform, and every sprint leaves a planning record that shows the capacity reasoning behind the number — the kind of decision trail public-sector reviews increasingly expect.

FAQ

Should we report velocity to leadership?
Not as a performance metric. Report predictability instead — the percentage of committed work delivered. Velocity is an internal planning input; publishing it as a scorecard invites estimate inflation.

How many sprints of history do we need after a roster change?
Three comparable sprints is a workable minimum. Until you have them, lean harder on the availability ledger and commit conservatively — a small promise kept builds more credibility than a large one missed.

Does this work with hours instead of story points?
Yes. The availability ledger is identical; you simply compare estimated hours directly against available person-hours and skip the ratio conversion.

Try it: Install Sprint Planning with Capacity Planning for Jira free from the Atlassian Marketplace, or start with the help docs and run the ten-minute availability ledger before your next planning session.