User Guide

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.

SprintVitals 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.

• 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.
• Average — trailing completed points across recent closed sprints (the window you set in Settings). Treat it as planning input, not a target to hit. Gaming the average destroys its value.
• Custom Completion (User Defined) — use this when Jira Doneis not the definition of done you want to measure (for example, work parked in a "Ready for release" column). It lets you count completion the way the team actually ships. Cancelled statuses are excluded here too.
• Backlog Health — a snapshot of refined, pointed work for the upcoming sprint, taken during the current one. 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 sprint, save a Backlog Health snapshot. Compare refined ticket count and refined points to the trailing Average. 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 the Average 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 the Average?
• 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 Custom Completion and Completed diverge: what does "done" mean for this team, and are we measuring the right column?

Configure Dashboard Average and Custom Completion 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.