Manual

Jira's native Sprint Report is built for one sprint at a time. That is enough to close a sprint. It is not enough to inspect and adapt over a stretch of work. Continuous improvement depends on patterns: whether commitments hold, whether the sprint goal is protected, whether unfinished work is becoming a habit, and whether refinement is actually producing ready work before planning.

Sprint Vitals puts those signals in one table so the team starts from a shared, factual view — not from memory, and not from a single-sprint scorecard. Use the numbers to open a conversation. Do not use them as a performance rating.

The table is grouped into Intake, Delivery, and Quality. Intake holds the planned window, Backlog Health, Health Indicator (refined points ÷ Velocity (N)), Velocity (N), and the sprint goal. Delivery holds committed, updated scope, added, removed and cancelled, completed, Predictability (completed ÷ committed), and spillover. Quality holds Defects Created, Defects Closed, and Escaped Bugs. Each sprint has a comment under those three groups. Three trend charts sit with the table: Backlog health, Predictability, and Sprint delivery. Blocked stories, updated scope, and stale tickets are the tactical indicators; they have their own section below. The list here is what to read in refinement, planning, and the retro.

• Committed vs completed — the empirical record of forecast quality. A one-sprint miss is noise. Several sprints of over-commitment is a planning conversation.
• Added mid-sprint — whether the sprint goal was protected. Rising added scope is often a process signal (intake, interrupts, unclear ready), not a heroics story.
• Removed & Cancelled — work that left the sprint, or stayed in scope but moved to a Cancel / Cancelled / Canceled status. Cancelled work is not treated as velocity.
• Completed — in-scope work whose status category was Done when the sprint closed. Cancelled statuses are excluded. Work that was removed from the sprint but finished during it still counts as completed.
• Spillover — in-scope work that was not completed: (committed + added) − completed. Recurring spillover usually means items are too large, too unclear, or the sprint is overloaded. Finished-then-removed work does not land here. Unfinished work that left the sprint is not Completed, but it still sits in Spillover.
• Velocity (N) — trailing completed points across recent closed sprints. N is the window you set under Dashboard Velocity in Settings. Treat it as planning input, not a target to hit. Gaming the number destroys its value.
• Predictability — completed ÷ committed. Completed is Jira Done at sprint close, with cancelled work excluded. Color bands show whether the commitment held. Read the trend in the retro. Do not use it as a performance rating.
• Health Indicator — Backlog Health refined points ÷ Velocity (N). It answers whether refinement covered about a sprint of ready work before planning. N/A when a snapshot or Velocity is missing.
• Updated Scope — a change to the story after it was pointed and after the team committed to it. A count on the row; the list sits with Backlog Health. Details are in Tactical indicators.
• Quality — Defects Created, Defects Closed, and Escaped Bugs. Defects stay out of committed, added, completed, and spillover so delivery is not mixed with bug traffic.
• Backlog Health — a snapshot of refined work across the next three future sprints(union), taken during the current one. Refined means story points > 0 and not a cancelled-named status. The same section lists the tactical indicators: blocked stories, updated scope, and stale tickets. It answers the question planning cannot: did refinement produce enough ready work, or will the sprint be invented in the planning meeting?

A practical cadence is enough. You do not need to live in the dashboard. Open it at three moments: after refinement, before planning, and in the retrospective.

• Product Backlog refinement (during the current sprint)— as the team points and clarifies work for the next few sprints, save a Backlog Health snapshot (union of the next three future sprints). Read the tactical indicators on that snapshot — blocked stories, updated scope, and stale tickets — then compare refined ticket count and refined points to the trailing Velocity (N). If the snapshot is thin with a few days left, schedule another refinement session before planning — that is the intervention, not a last-minute pointing rush in the planning meeting.
• Sprint Planning— put the latest closed rows and Velocity (N) on the screen. Ask: given what we actually completed recently, and given how much refined work is in the snapshot, what commitment is honest? Use recent Added and Spillover as constraints. A team that added a lot last sprint, or carried a lot over, should not plan as if the board was empty and quiet.
• During the sprint— glance at added scope when the sprint goal is at risk. The Daily Scrum stays with the Developers; the dashboard is a cue, not a status meeting. If added work keeps growing, surface it with the Product Owner: is this more important than the goal, or should it wait?
• Sprint Review and Retrospective— spend about fifteen minutes on the newest row against the last three or four. Walk committed vs completed, added, removed and cancelled, spillover, and the backlog-health snapshot that fed this sprint. Ask what the pattern suggests — not who missed a number. Then pick one process change for the next sprint (smaller items, firmer ready, fewer mid-sprint adds, more refinement time).

• If completed is consistently below committed: are we forecasting from hope, or from Velocity (N)?
• If added keeps rising: what intake rule would protect the sprint goal without hiding real interrupts?
• If spillover repeats: which items are too large or too unclear to finish in one sprint?
• If Backlog Health is low at planning: where did refinement lose time, and what will we protect next sprint?
• If blocked stories, stale tickets, or updated scope keep showing up with Backlog Health: which of those is holding ready work back, and what will refinement clear before planning?
• If escaped bugs keep showing up: is Done meaning released, or only moved to the last column?

Configure Dashboard Velocity and the Health Indicator and Predictability color bands per board so the table matches how this team works. Those options, plus install and first-time setup, live in Installation and Setup. Then keep the ritual small: snapshot after refinement, check readiness before planning, read the new row in the retro.