Short answer: To forecast next quarter from past velocity, convert velocity into points per available person-day, then multiply by the person-days you will actually have in each sprint. Present the result as a range, not a single number.
Every fiscal quarter, someone up the chain asks the same question: “What will your team deliver by December 31?” With staff reductions and flat budgets, the honest answer matters more than the comfortable one. “Fewer people, same mission” only works if the forecast reflects the people you actually have.
Why does multiplying average velocity by the number of sprints fail?
Average velocity quietly assumes every future sprint looks like the past ones. In government it rarely does. The October-to-December quarter contains Indigenous Peoples’ Day, Veterans Day, Thanksgiving, the winter holidays, and the use-or-lose leave that clusters at year end. A velocity of 40 earned in a full-staff September says little about a sprint where a third of the team is out.
How do you build a capacity-adjusted velocity forecast?
Use this five-step framework.
- Pull the last three to six completed sprints. Record completed points (not committed) and the person-days that were available in each sprint after holidays, leave, training, and part-time allocation.
- Compute points per available person-day for each sprint. Completed points divided by available person-days. This normalizes away the sprints that were short-staffed.
- Take a low, middle, and high ratio. The lowest, median, and highest of your recent sprints give you a defensible range.
- Map next quarter’s calendar. For every sprint, list available person-days: subtract federal holidays, scheduled leave, mandatory training, and any detail assignments.
- Multiply and sum. Available person-days times each ratio, summed across sprints. Commit to the middle number and report the range.
What does a worked example look like?
Take a six-person team running two-week sprints. Over the last three sprints they completed 42, 38, and 46 points on 54, 54, and 51 available person-days. That gives roughly 0.78, 0.70, and 0.90 points per person-day, with a median near 0.78. We will round the range to 0.70 (low), 0.80 (middle), 0.90 (high).
Next quarter’s six sprints have these available person-days after holidays and planned leave:
- Sprint 1: 54
- Sprint 2: 48 (Veterans Day, one training day)
- Sprint 3: 40 (Thanksgiving week, two people on leave)
- Sprint 4: 36 (winter holidays)
- Sprint 5: 50
- Sprint 6: 52
The total is 280 person-days. At 0.70, 0.80, and 0.90 points per day, the forecast is 196, 224, and 252 points. The naive method (six sprints at an average of 42) would have promised 252 points, which is only the optimistic end of the range. Reporting “about 224, likely between 196 and 252” tells leadership the truth and gives them a basis to prioritize scope.
How should you report the forecast up the chain?
Lead with the range and the assumptions: team size, leave already on the calendar, and the ratio used. Name what would change the forecast, such as a lost team member or an added detail. When a number moves, you can show exactly which input moved it. This is also a record of who was allocated, which days off were subtracted, and why the team committed to its figure. It is a planning record, not a compliance outcome, but it answers the “what changed and why” question that reviewers ask.
How does doing this in Jira make it repeatable?
The framework is simple; the effort is in the bookkeeping. Collecting leave, holidays, and allocation percentages in a spreadsheet and then reconciling them against Jira velocity is where forecasts go stale. Sprint planning with Capacity Planning for Jira puts past velocity, days off, and allocation on one screen inside the Jira backlog, so available person-days for each sprint are visible before you commit. It is a Cloud Fortified app that runs on Atlassian’s SOC 2 Type II / ISO 27001 certified cloud platform, which fits agencies moving their planning work onto Atlassian Cloud. A practical start: take your next quarter’s calendar and build the six-sprint table above before your next planning session.
FAQ
How many past sprints should I use?
Three to six completed sprints. Fewer is too noisy; more can include a team composition that no longer exists.
Should I include sprints that were disrupted?
Yes, normalized by available person-days. That is the point of the ratio: a disrupted sprint still informs points per available day.
Is a velocity forecast a commitment?
No. Commit sprint by sprint; use the quarterly forecast as a planning range that you update after each sprint.
Try it: Install free on the Atlassian Marketplace · Help docs
Leave a Reply
Your email is safe with us.