Short answer: To forecast a quarter from past velocity, count the sprints that actually fit in the quarter, build a velocity range from your last three to six sprints with stable team composition, scale that range by how much of your normal availability the quarter actually gives you, then hold back a reserve for unplanned work. The output is a defensible band — not a single number — with every assumption written down.

Every fall, some version of this email lands in a program manager’s inbox: “Leadership needs the Q1 delivery commitment by Friday.” The team has been running two-week sprints for a year, the burndown charts look fine, and yet the honest answer is a shrug. Someone multiplies last sprint’s velocity by six, rounds up, and sends it. Three months later the team has delivered two-thirds of it, and the conversation in the quarterly review is about credibility rather than software.

The math isn’t hard. What makes quarterly forecasting fail in government is that the standard formula — average velocity times number of sprints — quietly assumes a calendar and a roster that public-sector teams do not have.

Why government quarters break naive velocity math

Three things distort the picture, and all three are getting worse as agencies absorb workforce reductions and flat budgets.

• The quarter is shorter than it looks. Thirteen weeks does not equal six and a half clean sprints. Federal holidays cluster in the fourth calendar quarter, end-of-year leave-use deadlines push accrued PTO into December, and mandatory annual training lands whenever the compliance office says it does.
• The team that produced your velocity history may no longer exist. After a departure, a detail assignment, or a hiring freeze that leaves a billet empty, historical velocity describes a team you no longer have. Averaging across the change is the single most common forecasting error we see.
• Unplanned work is not noise; it’s a standing tax. Production defects, legislative or rule changes, data calls, and evidence requests for an ongoing authorization effort arrive every quarter. A forecast that assumes zero unplanned work is wrong by design.

How do you forecast a quarter from past velocity?

Five steps. Do them in this order — each one narrows the number honestly rather than optimistically.

1. Count the sprints that actually exist. Lay the sprint calendar over the quarter and mark any sprint that straddles a shutdown week, a fiscal-year boundary, or a release freeze. If a sprint has fewer than seven usable working days, don’t count it as a full sprint.
2. Build a velocity band from stable sprints only. Take your last six completed sprints and cut the history at the last change in team composition. Use what remains. Your band is the low and high of those sprints, not their mean. If fewer than three stable sprints remain, say so in the forecast.
3. Scale by real availability — measured against your reference sprints. Compute person-days available in the quarter after holidays, approved leave, training, and partial allocations. Then compare that to the availability your reference sprints actually had, not to a theoretical 100%. Comparing against 100% double-counts the holidays already baked into your velocity.
4. Hold back a reserve for unplanned work. Look at the last two quarters and calculate what share of delivered points went to work that wasn’t in the sprint at planning time. For most public-sector teams this is 10–20%. Use your own number, not a rule of thumb.
5. Publish the band with named assumptions. One page: the range, the sprint count, the availability figure, the reserve percentage, and the specific conditions that would invalidate it (“assumes the vacant senior developer billet is not filled this quarter”). This is what turns a guess into a decision record.

A worked example

A state health agency team is modernizing an eligibility determination system. Five people, two-week sprints, forecasting 1 October through 31 December.

Step 1 — sprints. Six sprints fit the window. The last one overlaps the holiday period but still has eight usable days, so it counts.

Step 2 — velocity band. Last six sprints: 34, 41, 28, 38, 36, 31. A senior developer left after sprint 3 and the billet is frozen. Only sprints 4–6 describe the current team: 31 to 38 points. Nominal quarter = 6 × (31 to 38) = 186 to 228 points.

Step 3 — availability. Baseline is 5 people × 10 days × 6 sprints = 300 person-days. Deductions:

• Four federal holidays × 5 people = 20
• Day after Thanksgiving, 4 people out = 4
• Approved December leave, 3 people × 4 days = 12
• Security awareness and Section 508 training, 5 people × 1.5 days = 8
• One developer detailed 30% to an assessment evidence package = 18

Total deducted: 62. Available: 238 of 300, or 79%. The reference sprints (4–6) ran at 92% availability. So the scaling factor is 79 ÷ 92 = 0.86. Adjusted band: 160 to 197 points.

Step 4 — reserve. Last two quarters, 15% of delivered points went to unplanned defects and data calls. Apply 0.85: 136 to 167 points.

Step 5 — publish. “We forecast 136 points of planned scope for Q1, with upside to 167 if unplanned work stays at historical levels. Assumes the vacant developer billet remains unfilled and the 30% detail continues through December.”

That last sentence is worth more to a program manager than the number in front of it. It converts a forecast into a conversation about trade-offs — fill the billet, end the detail, or cut scope — instead of a promise nobody can keep.

Making this repeatable instead of heroic

None of this is hard once. It’s hard every quarter, in a spreadsheet, by hand, while the underlying Jira data keeps moving. The spreadsheet is stale the moment someone books leave, and the reasoning behind last quarter’s number lives in a tab nobody can find.

This is the practical case for doing capacity work where the backlog already lives, as part of the broader move to Atlassian Cloud and Atlassian Government Cloud. Sprint planning with Capacity Planning for Jira puts past velocity, days-off, and per-person allocation on one screen inside the Jira backlog, so you set the commitment while looking at what the team actually has — before you commit, not after. It’s a Cloud Fortified app running on Atlassian’s SOC 2 Type II / ISO 27001 platform. Planning in the tool of record also leaves a trail: who was allocated, what days-off were subtracted, and why the team committed to N points. When someone asks in March how the Q1 number was set, the answer is in the system rather than in someone’s memory.

FAQ

How many sprints of velocity data do I need before I can forecast a quarter?
Three completed sprints with unchanged team composition is the practical minimum. Six is better. What matters more than the count is that nothing structural changed across them — a single departure or new detail assignment resets the clock.

Should I give leadership one number or a range?
A range, with the low end labeled as the commitment and the high end as upside. A single number reads as a promise and gets treated as one. A range with stated assumptions invites the trade-off conversation you actually want.

What if the team has no velocity history at all?
Forecast in available person-days rather than points, mark the forecast provisional, and recalibrate after sprint three. Publishing “we don’t know yet, here is when we will” is more credible than publishing a number you invented.

Try this before your next quarterly planning session

Build a one-page forecast worksheet with five lines: sprint count, velocity band from stable sprints, availability percentage versus reference sprints, reserve percentage, and the resulting range. Fill it in for the current quarter and compare it to what you actually committed. The gap between those two numbers is your forecasting debt.

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