Picture a quarterly program review at a state agency. The scrum master proudly reports that the team’s velocity has climbed from 28 to 34 story points over the last three sprints. Leadership nods. Then the next sprint lands in the middle of the July 4th week, two engineers are pulled onto a security-audit response, and the team delivers 19 points. Suddenly the “trend” looks like a collapse, and a program manager has to explain to a steering committee why delivery “dropped 44%.”
Nothing actually went wrong with the team. What went wrong was the planning model. The team committed to a number based on velocity when it should have planned against capacity. These two words get used interchangeably in government agile rollouts, and the confusion quietly drives most of the overcommitment, missed fiscal-year milestones, and credibility problems that public-sector PMOs struggle with.
The difference in one sentence
Velocity is a backward-looking average of how much work a team has completed per sprint. Capacity is a forward-looking estimate of how much work a team can complete in the specific upcoming sprint, given who is actually available. Velocity describes a typical sprint. Capacity describes the next one — the one with the holiday, the detail assignment, the mandatory training, and the half-time contractor in it.
Velocity is necessary but not sufficient. It tells you the team’s general throughput. It says nothing about whether this particular two weeks looks like a normal two weeks. In government, almost no two weeks look normal.
Why the gap hurts public-sector teams more
Commercial teams often run with stable, full-time staff and can absorb a bad sprint inside a flexible roadmap. Government teams rarely have that cushion. A typical agency team carries a mix of full-time federal staff, contractors with fixed hours, and people who are “matrixed” — officially on your team but routinely pulled to other priorities. Layer on federal holidays, use-or-lose leave at fiscal year-end, mandatory cyber and ethics training, and continuing-resolution uncertainty, and the availability of your team swings wildly from sprint to sprint.
When you plan against a flat velocity number, you are implicitly assuming every sprint has the same available hours. The sprints where that assumption breaks are exactly the ones that show up in oversight reports as failures.
A framework for getting it right
You do not need to abandon velocity. You need to use velocity and capacity together, in sequence.
- Establish a velocity baseline. Average the completed story points from your last three to five comparable sprints. Throw out anomalies (a sprint cut short by a shutdown, for example) so the baseline reflects a representative pace.
- Calculate capacity for the next sprint, in person-days. Start from the raw working days in the sprint, then subtract holidays, planned leave, training, and the share of time matrixed people actually give you. This is the step most teams skip.
- Convert capacity into a commitment ceiling. Express your baseline velocity as points-per-available-person-day, then multiply by the capacity you just calculated. This translates “we usually do 34” into “this sprint we can responsibly commit to X.”
- Plan the backlog to the ceiling, not above it. Pull in stories until you reach the adjusted number, and stop. Resist the urge to round up because the burndown chart “looked good last time.”
- Reconcile after the sprint. Compare planned capacity, committed points, and completed points. Over a few sprints this tells you whether your matrix-allocation assumptions are honest.
A worked example
Take a six-person team running a two-week (10 working day) sprint. Baseline velocity over the last four sprints is 40 points. That means 40 points across roughly 60 person-days, or about 0.67 points per available person-day.
Now look at the actual upcoming sprint:
- Two full-time developers, fully available: 2 × 10 = 20 days
- One developer taking 3 days of leave: 7 days
- One developer with a 2-day mandatory training: 8 days
- One half-time contractor: 5 days
- One analyst matrixed at 40% to another program: 4 days
- Subtract one agency-wide holiday for the four full-day-eligible staff: −4 days
Available capacity = 20 + 7 + 8 + 5 + 4 − 4 = 40 person-days, versus the 60 the velocity baseline assumed. Multiply 40 days × 0.67 points/day ≈ 27 points. So the honest commitment ceiling for this sprint is about 27 points — not 40. A team that commits to 40 here isn’t being ambitious; it’s planning to miss by a third, and that miss will be read as a performance problem rather than a calendar one.
Making it repeatable inside Jira
The math above is not hard. Doing it reliably, every sprint, for every team, while the inputs keep changing — that is the hard part. Most agencies attempt it in a side spreadsheet that one person maintains and nobody trusts by month three. The moment that person is on leave, the team falls back to flat velocity and the cycle repeats.
This is where keeping capacity and sprint planning on a single screen, inside the backlog you already use, changes the habit. Sprint Planning with Capacity Planning for Jira lets you see past velocity, each person’s days-off, and their allocation alongside the work you’re about to commit — before you commit it — so the adjusted ceiling is visible at the moment of decision instead of buried in a spreadsheet. It’s a Cloud Fortified app that runs on Atlassian’s SOC 2 Type II / ISO 27001 platform, so it fits inside the governance posture your agency already relies on. The result is a planning record that shows not just what the team committed to, but the capacity reasoning behind it — useful when you’re explaining a number to a steering committee.
The takeaway
Velocity tells you how fast the team tends to go. Capacity tells you how far it can go this specific sprint. Government teams that report against velocity alone keep setting themselves up to “fail” on the sprints that simply had fewer working hours in them. Plan to capacity, reconcile against velocity, and your delivery story becomes defensible — because it matches the calendar your stakeholders are actually living in.
Try it: Install free · Help docs
Go deeper: our complete sprint planning guide turns velocity-vs-capacity into a repeatable planning process.
In Jira: see how velocity and capacity feed a full step-by-step sprint planning in Jira workflow.
2 Comments
Leave your reply.