To report sprint predictability to non-technical government leadership, stop presenting a single “on track” date. Present a forecast range — optimistic, likely, and conservative — built from the team’s recent completed work, state in plain words whether that range clears the deadline that matters, and end with the one decision you need from the room. A range with a verdict is harder to misread than a green status box, and it surfaces bad news while there is still time to act on it.

Every steering committee eventually meets a watermelon status: green on the outside, red on the inside. Picture a PMO lead at a state health agency running an eligibility-system modernization against a statutory mandate that takes effect January 1. Her delivery team lost two of seven positions in a June reorganization. The deck still shows green — because the milestone plan was approved in March, around a team that no longer exists. Nobody is lying. The reporting format simply has no place to say “our capacity changed, and the dates moved with it.”

Why “on track” is the most dangerous phrase in a steering committee

The format problem is sharper in government than in most commercial settings. Public-sector leaders carry a forecast upward into rooms where revising it is expensive — budget hearings, legislative briefings, oversight reviews. A product team that misses a quarter ships a quarter later; an agency that misses a statutory date can trigger findings, penalties, or public scrutiny. So the people in the middle keep statuses green as long as humanly possible, and small slips quietly compound into a December surprise.

Workforce reductions make this worse, not better. Across federal, state, and local agencies, the input that moves delivery dates most — how many people are actually available — now changes more often than the reporting formats built to describe it. Fewer people and the same mission means the forecast has to be recomputed from real capacity every sprint, not restated from the original plan.

What should a sprint predictability report contain?

One page, five elements. Call it a delivery confidence brief.

1. A range, not a date. Take completed points per sprint — only from sprints that resemble the team you have today — and pull three numbers: best, average, worst. Divide remaining scope by each to get three sprint counts, then convert those into three calendar dates. The range tells leadership the honest shape of the future: earlier than the best case is unlikely, later than the worst case is unlikely, and the middle is the planning number.
2. A verdict against the deadline. Non-technical readers should never have to do calendar math. Say it in words: “the likely case finishes four weeks before the mandate; the conservative case finishes one week after.” Fits, tight, or misses.
3. What moved since the last brief. Only two forces move a forecast: scope added or removed, and capacity gained or lost. Give each one line — “scope +26 points (new interface requirement); capacity −1 developer (detailed to another program).” Leaders stop being surprised by moving dates once they can see the forces that move them.
4. One decision request. A brief that ends with “any questions?” produces sympathy. A brief that ends with a decision produces action: defer these work items, extend this date, accept this risk, or restore this position. Name the option you recommend.
5. Evidence one click away. Behind the range should sit the planning record: who was allocated to each sprint, which holidays and days off were subtracted, and what the capacity math showed when the team committed. Oversight bodies increasingly expect agencies to show who acted, what changed, and what evidence supported a decision — and a briefing that can point to its planning record ages far better than one built on recollection.

A worked example: catching a January miss in August

A five-person state team runs two-week sprints. In the five sprints since the June staffing change it completed 24, 29, 26, 31, and 25 points — average 27, best 31, worst 24. The backlog for the mandated release holds 270 remaining points, and the next sprint starts August 17. The range:

• Optimistic: 270 ÷ 31 → 9 sprints, finishing in mid-December
• Likely: 270 ÷ 27 → 10 sprints, finishing in the first days of January
• Conservative: 270 ÷ 24 → 12 sprints, finishing in early February

The verdict writes itself: the likely case lands on or just past the January 1 mandate, and the conservative case misses it by a month. Surfaced in August, that is a scope conversation; discovered in November, it is an incident. So the brief ends with a request: defer 54 points of lower-priority work now. At 216 points, the likely case finishes in early December and even the conservative case finishes around December 21 — ahead of the mandate, with margin restored.

Making the range repeatable inside Jira

A range is only as credible as its inputs, and the inputs — completed velocity, who is allocated at what percentage, whose leave falls inside the sprint — are usually scattered across a reporting tool, a leave calendar, and the plan in someone’s head. As agencies modernize onto Atlassian Cloud and Atlassian Government Cloud (AGC), it makes sense to plan where the backlog already lives. Sprint planning with Capacity Planning for Jira puts past velocity, allocation, and days off on one screen inside the Jira backlog, so the team sees its real capacity before it commits — and every later brief reads from the same record the commitment was made on. The app is Cloud Fortified and runs on Atlassian’s SOC 2 Type II / ISO 27001 platform.

FAQ

What if leadership insists on a single date? Give the likely date with the range attached: “early January, with a range from mid-December to early February.” Most leaders who see the range once ask for it again — it is the version that protects them in the rooms you are not in.

How much sprint history do you need for a credible range? Three sprints is the floor; five or six is comfortable. The one hard rule: use only sprints that resemble the team you have now. After a significant staffing change, restart the window.

Should the brief include story points? Keep them in the appendix. The brief itself should speak in dates, ranges, and decisions; the point math is the evidence behind it, not the message.

Try it: Install Sprint planning with Capacity Planning for Jira free from the Atlassian Marketplace · Help docs