To forecast a quarter from past velocity, convert your last five or six sprints into a throughput rate — points delivered per available person-day — and multiply that rate by the person-days you will actually have next quarter, after holidays, PTO, training, details, and departures. Forecasting on average velocity alone systematically overcommits, because that average was earned by a team whose staffing picture no longer exists.

A state permitting-modernization team promised its steering committee 200 story points for the coming quarter. The arithmetic looked unimpeachable: six sprints, average velocity 33, call it 200. What the number did not carry was that an analyst was leaving in six weeks and would not be backfilled, that the whole team had a mandatory training day, and that a senior developer had been half-committed to an incident-response effort. The team delivered 168. Nobody had lied. The forecast was a rate applied to a team that had already changed.

Why average velocity breaks down in government

Velocity is not a property of a team. It is a rate observed under conditions — a particular headcount, working a particular number of days, with a particular share of their attention. Every forecast built on velocity is implicitly a bet that next quarter’s conditions resemble last quarter’s.

In the public sector, that bet is worse than it looks. Staff get detailed to other programs mid-quarter. Collateral duties and mandatory annual training land on fixed dates. Fiscal-year and contract boundaries reshuffle who is on the team at all. And with flat budgets and workforce reductions across FedCiv, DoD, and State & Local, the most common change to a team’s conditions right now is subtraction — a departure with no backfill, while the mission stays exactly the same size.

The stakes are also different. In a commercial setting a missed forecast is a disappointing sprint review. In an agency, the quarterly number goes into a milestone report, a steering-committee deck, and sometimes an obligation plan. Overshooting is not embarrassing so much as expensive.

How do you forecast a quarter using past velocity?

Five steps. The whole thing takes about forty minutes once a quarter.

1. Pick a clean history window. Use your last five or six completed sprints. Exclude sprints that were structurally abnormal — the sprint you spent on an emergency, the sprint you cut short for a release freeze. You are looking for a rate, not a trophy.
2. Convert velocity into a throughput rate. This is the step almost everyone skips. Total the points delivered in the window, then total the available person-days that produced them — actual working days, already net of the PTO and holidays the team really took. Divide. You now have points per available person-day, a number that survives changes in headcount.
3. Build forward capacity honestly. Lay out next quarter’s sprints. Start from nominal person-days, then subtract: federal holidays, approved PTO, training days, known details and rotations, and any departure or arrival with its actual effective date. Do not subtract a vague “buffer” — subtract named days for named reasons.
4. Multiply, then express the answer as a range. Rate × available person-days gives you a point estimate. Then take the best and worst per-day rates from your individual sprints in the window and multiply those too. The spread between them is your honest forecast range. Commit near the bottom; plan the top as stretch.
5. Write down the assumptions next to the number. Three lines is enough: what rate you used, what days you subtracted, and what you are assuming that could turn out false. This is what makes the forecast defensible when someone asks in October why the number was what it was.

A worked example

Six-person team, two-week sprints, six sprints in the quarter.

History (last six sprints): 34, 28, 41, 31, 36, 30 = 200 points, delivered across 320 available person-days.

Throughput rate = 200 ÷ 320 = 0.625 points per available person-day.

Forward capacity:

• Nominal: 6 people × 10 days × 2 sprints, then 5 people × 10 days × 4 sprints (the analyst departs after sprint 2) = 320 person-days
• Less 2 federal holidays: −11 person-days
• Less approved PTO: −22 person-days
• Less mandatory annual training day: −5 person-days
• Less one engineer detailed 50% to incident response for sprints 4–5: −10 person-days

Available = 272 person-days.

Forecast = 272 × 0.625 = 170 points. Range, using the team’s best and worst observed per-day rates (0.55 to 0.72): 150 to 196 points.

The naive forecast — six sprints at an average velocity of 33 — would have been 200. The gap is 30 points: an entire sprint of work promised that the team does not have the days to do. Notice also that the departure alone accounts for less than half the gap. Days off, training, and one half-detailed engineer quietly take the rest.

Why this belongs on one screen inside Jira

The reason teams skip step two is not that the math is hard. It is that the inputs live in four places: velocity in Jira, PTO in a leave system, details in someone’s email, and the forecast itself in a spreadsheet that one person maintains and nobody else can audit. Every quarter, that spreadsheet is rebuilt from memory, and the assumptions evaporate.

Doing it where the work already lives fixes that. Sprint planning with Capacity Planning for Jira puts past velocity, days-off, and allocation on one screen in the Jira backlog, so you can see real capacity before you commit rather than after. It is part of the same modernization move agencies are already making onto Atlassian Cloud and Atlassian Government Cloud (AGC) — getting planning out of parallel spreadsheets and into the system of record. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

There is a side benefit worth naming. Buyers across the public sector are under real pressure to show their work — who was allocated, what changed, and what supported a decision. A capacity plan that lives next to the backlog leaves a record of exactly that: who was on the team, what days were subtracted, and why the team committed to N points instead of N+30. That is a decision trail, and it is far easier to produce from a tool than to reconstruct from an inbox.

FAQ

How many sprints of history do I need before I can forecast a quarter?
Five or six completed sprints is the practical minimum for a usable range. With three you can still compute a rate, but present it as a range only and say plainly that it will tighten. Do not wait for perfect history — an explicit wide range beats a confident wrong number.

What if my team’s composition changes so much that past velocity is meaningless?
That is exactly what the throughput rate is for. Points-per-person-day is comparatively stable across headcount changes, where raw velocity is not. It does break down when the change is in skill mix rather than volume — losing your only database engineer is not a 17% capacity cut, it is a dependency. Note those separately as risks, not as arithmetic.

Should I give leadership the range or the point estimate?
Give both, in that order: the range first, then where inside it you are committing and why. A single number invites the question “is that a promise?” A range with a stated commitment answers it before it is asked.

Try this next quarter

Before your next quarterly review, do one pass: pull your last six sprints, compute points per available person-day, and build the forward capacity subtraction list for the coming quarter. If the gap between that number and your naive velocity forecast is more than half a sprint, you have found the exact conversation worth having with your steering committee — with the arithmetic to back it up.

Try it: Install free · Help docs