Why Jira’s single-sprint report isn’t enough

Scrum Masters, team leads, and engineering managers on Jira Cloud Scrum who already run a sprint review, then still rebuild the story in a spreadsheet for stakeholders.

If your only view of delivery is the native Sprint Report for the sprint that just closed, you can answer “what finished this time?” You cannot reliably answer “are we keeping the promise across the last several sprints?”

Sprint health is not a single velocity number. It is a short set of facts you can inspect together:

• Committed — what the team pulled at planning (the promise).
• Completed — what met Done by close.
• Added / removed / cancelled — scope change after the promise.
• Spillover — work that rolled because it did not finish.
• Trailing velocity — recent completion, not one lucky sprint.
• Predictability — finished ÷ committed over time, frozen at close so the chart does not rewrite history.

Those numbers answer one honest question: Did we keep the promise? They sit next to readiness (were we ready to plan?) and Done quality (was finished actually finished?). Ranking people is not the point.

Jira’s Sprint Report is useful for the sprint you have open. Continuous improvement is a pattern problem. Patterns need several sprints side by side.

Without a multi-sprint view, teams fall into the Friday export: open last sprint, copy committed and completed, open the one before, paste again, argue about mid-sprint adds, then build a chart leadership will only half trust because the method changes every month.

That spreadsheet becomes the real system of record. Jira stays the place work lives. The SM becomes the ETL pipeline.

1. Committed at planning — freeze what “the promise” was.
2. Completed at close — only work that met your Done statuses.
3. Scope added after planning — interrupts and “quick” inserts.
4. Removed or cancelled — promise reduced on purpose vs quietly dropped.
5. Spillover into the next sprint — unfinished carry that eats the next plan.
6. Predictability (completed ÷ committed) — trend it; one green sprint does not fix a red pattern.

Optional quality pair: defects created vs closed, and escaped bugs that showed up after “Done.” Delivery without quality is a fake win.

Use this in the sprint review or a short delivery huddle — not a status theater monologue.

1. Show the last 4–6 sprints: committed vs completed on one chart.
2. Call out the biggest scope-add sprint. Ask what interrupted the plan.
3. Call out spillover. Ask whether planning over-pulled or blockers arrived late.
4. Read predictability as a trend, not a grade on individuals.
5. Pick one change for next planning: fewer commits, tighter Ready bar, or protected focus time — one lever, not five.

If the room only wants “are we faster?”, reframe to “are we more honest about the promise?” Speed without predictability is thrash.

Sprint Vitals is a Jira Cloud app for Scrum teams that keeps multi-sprint Intake, Delivery, and Quality on the board instead of in a side spreadsheet.

Delivery covers committed, added/removed/cancelled, completed, spillover, trailing velocity, and predictability (finished÷committed), frozen at close so history stays stable. Intake covers backlog readiness against velocity. Quality covers defects and escaped work so “Done” is inspectable.

A Jira admin approves Marketplace apps for the site. If you are the Scrum Master, send them the install link. The manual walks the dashboard after install.