48.9k Log in Get started
Dashboard

What does a sprint health dashboard show in Metabase?

A sprint (or cycle) health dashboard answers one question each iteration: are we on track to finish what we committed to? It tracks committed vs. completed work, spillover, and scope change. Build it from Jira sprints or Linear cycles synced into a database.

For: EMs, scrum leads, delivery. Grain: one iteration (sprint/cycle). Source: modeled issues + sprints/cycles (+ issue-iteration history for accurate scope change).

What does a sprint health dashboard look like?

Here’s the layout this guide builds, at the grain of a single iteration: commitment and burndown at the top, then scope change and velocity across recent sprints, then the cards that show where the sprint is slipping. Read it mid-sprint to see whether the commitment still holds, and at retro to see why it did or didn’t.

Sprint health dashboard in Metabase showing commitment, burndown, scope change, velocity, and spillover cards.

An example sprint health dashboard in Metabase, built from Jira sprints or Linear cycles. Figures are illustrative.

Which cards belong on a sprint health dashboard?

  • Committed vs. completed (points and issue count) for the current iteration
  • Spillover / carryover — items not finished in-iteration
  • Scope added after start — issues assigned after it began (needs history)
  • Burndown-style trend — remaining work over the iteration
  • Incomplete issues by team — where the iteration is slipping
  • Velocity trend — completed points over the last N iterations

What data does a sprint health dashboard need?

  • issues with estimate/story_points, state_type/status_category, and an iteration key.
  • sprints/cycles with start_date/end_date.
  • For scope change and burndown, issue-to-iteration change history — otherwise present current-state cards only and caveat the rest.

How do you build a sprint health dashboard?

  1. Sync sprints/cycles + issues (Jira / Linear).
  2. Model the iteration grain; define committed (in iteration at start) vs. completed (done by end).
  3. Build cards; add filters for team, board/cycle, and iteration.

Example card SQL

Committed vs. completed by iteration PostgreSQL 
SELECT
it.name AS iteration,
it.start_date,
SUM(i.estimate)                                                  AS committed_points,
SUM(i.estimate) FILTER (WHERE i.state_type = 'completed')        AS completed_points,
COUNT(*) FILTER (WHERE i.state_type <> 'completed')              AS spillover_issues
FROM iterations it
JOIN issues i ON i.iteration_id = it.id
GROUP BY it.name, it.start_date
ORDER BY it.start_date;

Integrations

Linear + Metabase Jira + Metabase

Dashboards

Software delivery dashboard

Metrics

Cycle time Lead time

FAQ

Sprint vs. cycle — does this work for both?
Yes. Jira calls the time-box a sprint, Linear calls it a cycle, and both are modeled the same way — a start date, an end date, and a set of issues with estimates. Every card here works whether you run Scrum sprints or Kanban-style cycles; only the label changes. See Jira and Linear for the connection.
Why is my scope-change (added-after-start) card empty?
Scope change needs the issue-to-iteration change history — a record of when each issue entered or left the sprint. Current-state snapshots only show where issues are now, so they can't reconstruct what was added or pulled mid-sprint. In Jira, derive it from the issue_changelog (Sprint field changes); in Linear, from issue history. Without history, hide the card and note the limitation.
How do I build a burndown chart in Metabase?
A burndown plots remaining work (open points or issues) against the days of the iteration. You need the iteration's start and end dates and, ideally, a status-change history so each item drops off on the day it's completed. Without history you can approximate an end-of-day snapshot, but a true burndown — and any mid-sprint scope change on it — requires the changelog.
What's a healthy committed-vs-completed ratio?
There's no universal number, but teams that reliably finish 80–90% of committed points sprint after sprint are estimating well; consistently under ~70% usually signals over-commitment, unplanned work, or too much work-in-progress. Watch the trend across iterations rather than any single sprint, and read it next to a cycle time trend.
Is velocity a good performance or comparison metric?
Velocity — completed story points per sprint — is useful for a team's own capacity planning but a poor performance or comparison metric. Points are estimated differently by every team, so cross-team velocity leaderboards are meaningless and pressure to raise velocity just inflates estimates. Use it to forecast the next sprint, not to rank teams or people.
How is this different from Jira's built-in sprint report?
Jira's sprint report is scoped to one board and one sprint. A Metabase sprint health dashboard joins many boards, teams, and iterations; tracks commitment reliability and spillover as trends over time; blends Jira and Linear data; and lets you define committed and completed once and share governed views across the org.
Which metrics belong next to sprint health?
Pair iteration-level cards with flow metrics: cycle time (how long items take once started) and lead time (created → done). Rising spillover together with rising cycle time is a strong signal the team is carrying too much work-in-progress into each sprint.