Capacity-aware backlog refinement is refinement that sizes and orders work against the team’s real available capacity for the next one or two sprints — actual person-days left after holidays, leave, training, and detail assignments — instead of against headcount. The output is a “ready” queue deliberately capped near what the team can absorb, so sprint planning becomes a short selection exercise rather than an argument.

Most refinement sessions in government fail quietly, and they fail after the meeting. A team spends an hour grooming stories, marks fourteen of them Ready, and walks into planning two days later to find that three of its seven people are at mandatory records-management training that week and a fourth has been detailed to pull evidence for an assessment package. The stories were well written. The acceptance criteria were fine. The queue was simply built for a team that will not exist during that sprint.

Why government backlogs drift out of sync with capacity

Every agile team deals with this. Public-sector teams deal with a harder version of it, for three structural reasons.

• Capacity is lumpy and externally controlled. Federal holidays cluster unevenly across the calendar. Mandatory training is scheduled by someone outside the team. Details, reassignments, and surge taskings arrive with little notice. Contractor staff roll on and off at task-order boundaries that have nothing to do with your sprint cadence.
• Fewer people, same mission. Workforce reductions and flat budgets do not shrink a statutory mandate or move a fiscal-year milestone. When staff shrink, the backlog usually does not. Refinement is the cheapest place left to reconcile the two — far cheaper than discovering the mismatch in sprint review.
• “Ready” gets read as “promised.” In agencies where delivery is reported up a chain, a Ready column is not a working convenience; it is a visible statement of intent. Marking work Ready that the team was never going to reach produces a documented pattern of unmet intent, which is exactly what a program manager gets asked about.

How do you run capacity-aware backlog refinement?

Five steps. None of them require a new ceremony — they change what happens inside the refinement session you already hold.

1. Open the session with a capacity number, not a story

Before anyone reads a ticket, put next sprint’s realistic capacity on the screen: nominal person-days minus holidays, approved leave, scheduled training, and any partial allocations. This single number reframes the entire hour. Refinement stops being “is this story clear?” and becomes “is this story clear, and does it fit?”

2. Cap the ready queue at roughly 1.5× expected delivery

A ready queue should be a buffer, not a warehouse. Somewhere around one and a half sprints of ready work gives you enough slack to swap items when priorities shift, without accumulating stories that go stale and need re-refining. Anything beyond that is refinement effort spent on work the team will not touch for a month — and requirements in government rarely survive a month untouched.

3. Size against the specific people, not the abstract team

A five-point story is only a five-point story if someone who can do it is available. If your only database engineer is out for eight of the ten sprint days, then every story that depends on schema work is effectively unsizable this sprint, regardless of its point value. Name the skill dependency during refinement, not during standup on day four.

4. Refine one to two sprints ahead — deliberately, not opportunistically

Teams under deadline pressure often over-refine, believing a deep ready queue is a form of preparedness. It usually is not. Set an explicit horizon, refine to it, and stop. The time you save goes into refining the near-term work properly.

5. Write down why an item was deferred

When you pull a story out of the ready queue because capacity does not support it, record the reason in one line on the ticket: “Deferred from Sprint 24 — QA lead at training 4 of 10 days; no second reviewer available.” This costs ten seconds and gives you something valuable later. When leadership asks in October why a capability slipped, you have a dated decision trail showing who was available, what was subtracted, and what the team chose — rather than a reconstruction from memory. Buyers across the public sector increasingly reward tools and practices that let them show what happened and what supported the decision; disciplined refinement produces that record as a byproduct.

A worked example

A seven-person team on two-week sprints, with a trailing three-sprint average velocity of 34 points.

Nominal capacity is 7 people × 10 working days = 70 person-days. Now subtract what the calendar already claimed:

• One federal holiday inside the sprint: −7 person-days
• Approved leave (two people, two days each): −4 person-days
• Mandatory annual security awareness training (three people, one day each): −3 person-days
• One engineer detailed at 50% to a documentation request: −5 person-days

Net available: 51 person-days, or about 73% of nominal.

Applying that ratio to velocity gives an expected delivery of roughly 34 × 0.73 ≈ 25 points, not 34. So the ready queue should be capped near 1.5 × 25 ≈ 37 points — not the 51 points a team would have queued up by reflexively applying 1.5× to its headline velocity.

That 14-point gap is the entire failure mode. It is not a large number, which is precisely why it survives refinement unnoticed and shows up as a missed sprint goal instead.

Making this repeatable inside Jira

The arithmetic above is not hard. Keeping it current is. When capacity lives in a spreadsheet on someone’s desktop, it is accurate the day it is built and decays from there — and the refinement session ends up using last month’s numbers, or no numbers at all.

This is a large part of why agencies moving to Atlassian Cloud, including Atlassian Government Cloud (AGC), are pulling planning work back into the tool where the backlog already lives. If velocity, days off, and allocation sit on the same screen as the backlog you are refining, the capacity check becomes a glance instead of a side project — and it happens every sprint instead of the sprints when someone remembered.

That is what Sprint planning with Capacity Planning for Jira does: it puts past velocity, days-off, and per-person allocation directly in the Jira backlog view, so you can see whether the queue you are building fits the team you will actually have before you commit. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

How far ahead should a government team refine its backlog?
One to two sprints of ready work, capped at roughly 1.5× expected delivery. Deeper queues in public-sector environments tend to go stale as priorities, taskings, and staffing shift, forcing you to re-refine the same items.

Should capacity reduce story points or just the number of stories pulled?
Neither — capacity should reduce how much work you mark Ready. Story points estimate size and should stay stable. Capacity estimates throughput, and it is what determines how many of those points the team can realistically carry into the sprint.

What if leave and details are announced after refinement?
Treat late capacity changes as a trigger to re-check the queue, not to push through the original plan. A two-minute recalculation at the start of sprint planning catches most of it; record what changed and what you deferred as a result.

Try this in your next refinement session

A five-question readiness check, before anyone opens a ticket:

1. What is our net available capacity for the next sprint, in person-days?
2. What percentage of nominal is that, and what does it do to our expected velocity?
3. Is our ready queue larger than 1.5× that number?
4. Does every ready item have an available person with the right skill?
5. For anything we defer, is the reason written on the ticket?

Run that for three consecutive sprints and you will have both a queue that matches reality and a written record of how you got there.

Try it: Install Sprint planning with Capacity Planning for Jira free · Read the help docs