Capacity-aware backlog refinement means sizing and readying only as much work as your team can realistically pull into the next one or two sprints, based on past velocity and the days people will actually be available. Refining beyond that creates stale detail; refining less leaves sprint planning to improvise.

When an agency loses headcount but keeps the mission, the backlog does not shrink. A program office with eight teams’ worth of requirements and five people’s worth of capacity still refines 200 stories because “that is what the roadmap says.” Then planning day arrives, half the stories are too big, and the team commits to the top of the list anyway. Refinement is the cheapest place to fix that.

Why does backlog refinement go wrong in government teams?

Three patterns show up repeatedly. First, refinement is driven by the requirements document or the contract deliverable list, not by what the team can finish. Second, refinement sessions ignore who is out; a story gets detailed for a specialist who will be on leave for the whole sprint. Third, “ready” is undefined, so approval chains, security review, and dependencies surface mid-sprint instead of beforehand.

The result is a backlog that looks thorough in a status report and behaves unpredictably in delivery. With flat or shrinking budgets, there is little slack to absorb that unpredictability.

How do you make refinement capacity-aware?

Work backward from capacity. Use these steps each refinement cycle:

1. Calculate next sprint’s available person-days. Start with working days times team size, then subtract federal holidays, planned leave, training, and any detail assignments elsewhere.
2. Convert history into a rate. Divide the average completed points of the last three sprints by the average available person-days in those sprints. This gives points per available person-day.
3. Set a refinement target. Multiply the rate by next sprint’s available person-days to get a forecast. Aim to have two sprints of forecast, plus about 10 percent, in a ready state. No more.
4. Agree on a definition of ready. A ready story has acceptance criteria, an estimate, named dependencies, and any required review (privacy, security, contracting officer) already scheduled.
5. Split anything that will not fit. A story larger than roughly a third of a sprint’s forecast should be broken down before it is eligible for planning.

What does a worked example look like?

Consider a five-person team running ten-day sprints. Over the last three sprints they completed 34, 38, and 36 points, averaging 36. Those sprints averaged 45 available person-days, so their rate is 36 / 45 = 0.8 points per available person-day.

Next sprint contains a federal holiday (1 day times 5 people = 5 person-days), one person on leave for 3 days, and a 2-day mandatory training for one teammate. That is 10 person-days off from a gross 50, leaving 40 available.

• Forecast for next sprint: 40 x 0.8 = 32 points.
• Following sprint, with no holidays and no planned leave: 50 x 0.8 = 40 points.
• Refinement target: 32 + 40 = 72 points, plus roughly 10 percent buffer, so about 79 points of ready stories.

If the backlog already holds 140 points of lightly refined stories, the team should stop refining at about 79 points and spend the saved time on splitting large items and clearing dependencies. The remaining 60 points stay as rough epics, honestly labeled as not yet ready.

How does this connect to what you report upward?

A capacity-based refinement target gives the PMO a defensible answer to “why is the team not detailing everything?” The answer is a documented calculation rather than a judgment call: here are the days available, here is the historical rate, here is the work that is ready. It also supports the broader public-sector expectation to show what was decided, by whom, and on what basis. That is a documentation habit, not a compliance outcome, but it makes planning decisions easy to explain and review.

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

The weak point of the method above is the arithmetic: availability lives in one spreadsheet, velocity in a Jira report, and the backlog in Jira itself. Someone rebuilds the numbers before every refinement session, and they are often stale by the time the meeting starts.

Sprint planning with Capacity Planning for Jira puts team capacity, past velocity, days-off, and allocation on one screen inside the Jira backlog, so you can see how many points a sprint can hold before you commit. During refinement, that view tells the team when the next two sprints are “full” of ready work. As agencies move planning workflows onto Atlassian Cloud, including Atlassian Government Cloud (AGC) for those who qualify, keeping this next to the backlog avoids another side system. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform. See the help docs for setup.

FAQ

How far ahead should a government team refine its backlog?

Usually one to two sprints of forecast capacity, plus a small buffer. Beyond that, detail tends to go stale as priorities, staffing, and funding change.

Should refinement time count against sprint capacity?

Yes. Refinement is real work. Either reserve a fixed share of capacity for it, or make sure your historical rate was measured while refinement was happening, so it is already included.

What if we have no velocity history yet?

Run two or three sprints, record completed work and available days, and use conservative estimates until a rate emerges. Do not borrow another team’s rate.

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