What is a release burndown, and how do you build one in Metabase?
A release burndown plots remaining scope — story points or item count — against time, toward a release date. It's the chart that turns "are we on track?" from a feeling into a projection, and the honest version has two lines: work burning down, and scope being added. Build it in Metabase from issue history synced from Jira, Linear, or Azure DevOps.
TL;DR — remaining points per day, from daily snapshots or replayed changelog history; a current-state sync cannot reconstruct the burn. Plot total scope on the same chart: the top line rising is scope creep, and it sinks more releases than slow burning does.
What does a release burndown measure?
Distance to done, and the rate you're closing it. Extend the burn line at its recent slope and it crosses zero on some date — that date versus the release date is the entire conversation. But the single-line version hides the most common failure mode:
- The burn line — remaining points per day. Its slope is the team's effective pace against this release, which should roughly match velocity — when it doesn't, work is leaking out of the release or estimates are drifting.
- The scope line — total points in the release per day. A flat burn line with a rising scope line means the team is delivering and the release is growing underneath them. On a one-line burndown that renders as "no progress," which is both demoralizing and wrong.
- Burndown vs. burnup — a burnup plots completed and total scope as two rising lines, making the gap (and its widening) explicit. Same data, better at attributing blame between pace and scope creep.
When the projection misses the date, the chart forces the cut-line decision early: which items drop below the line. Read weekly alongside task completion rate, it makes scope trade-offs a routine planning act instead of a launch-week scramble.
What data does it need?
- An
issue_snapshotsmodel: one row per issue per day withsnapshot_date,release,story_points, andstatus_category. - History is non-negotiable. A plain current-state sync overwrites the past on every refresh and cannot reconstruct the burn. Either replay the changelog (status changes, estimate changes, release membership changes) into daily rows, or run a scheduled job that snapshots current state each day going forward.
- Timestamps for scope events:
added_to_release_atandcompleted_atper issue, for the scope-added vs. completed view. - A consistent unit — points or item count. Item count is coarser but immune to estimate churn; pick one per chart and label it.
SQL patterns
Daily remaining points and total scope for a releasePostgreSQL
SELECT
snapshot_date,
SUM(story_points) FILTER (WHERE status_category <> 'done')
AS remaining_points,
SUM(story_points) AS total_scope_points
FROM issue_snapshots
WHERE release = '2026.08'
GROUP BY snapshot_date
ORDER BY snapshot_date;Scope added vs. completed per weekPostgreSQL
WITH events AS (
SELECT added_to_release_at AS event_at,
story_points, 'added' AS kind
FROM issues
WHERE release = '2026.08'
UNION ALL
SELECT completed_at, story_points, 'completed'
FROM issues
WHERE release = '2026.08' AND completed_at IS NOT NULL
)
SELECT
date_trunc('week', event_at) AS week,
SUM(story_points) FILTER (WHERE kind = 'added') AS points_added,
SUM(story_points) FILTER (WHERE kind = 'completed') AS points_completed
FROM events
GROUP BY 1
ORDER BY 1;Pitfalls
Building it on a current-state sync.→ The burndown is a history chart. If the pipeline only stores each issue's latest state, the remaining-points series simply doesn't exist — verify snapshots or changelog replay before promising anyone this chart.
Hiding the scope line.→ A flat burn line reads as "team stopped delivering" when the truth is often "team delivered 20 points while 20 arrived." Plot total scope on the same chart, or use a burnup, so the two causes are distinguishable.
Projecting from the best week.→ Extending the steepest recent slope makes every release look recoverable. Project from the rolling 3-sprint velocity average — pace over the last few weeks, not the single best one.
Treating unestimated items as zero points.→ Issues without estimates burn nothing when they close and add nothing when they arrive, so the chart quietly understates both scope and progress. Count them separately, or fall back to item count where estimation is patchy.
Where this metric applies
- Jira + Metabase — fix-version scope replayed from the issue changelog
- Linear + Metabase — project scope and estimates from issue history
- Azure DevOps + Metabase — iteration and work-item history
- Shortcut + Metabase — milestone scope and story states
Related
Metrics
Dashboards
FAQ
Burndown or burnup — which should I use?
They plot the same data; the burnup is just harder to fool. A burndown shows one line — remaining work — so when five points complete and five points of new scope arrive, the line goes flat and the chart can't say why. A burnup separates the two: a rising completed line under a rising total-scope line makes scope creep visible as a widening gap instead of a mysterious plateau. If your releases regularly gain scope mid-flight (most do), the burnup answers the questions the burndown raises.
Why does a release burndown need snapshot history?
Because "points remaining on June 3rd" is a fact about June 3rd, and a sync that only stores each issue's current state can't reconstruct it — once an issue closes or changes estimate, yesterday's remaining total is gone. You need either daily snapshots of every issue in the release or a changelog complete enough to replay (status transitions, estimate changes, and issues moving in and out of the release). If neither exists yet, start capturing snapshots now: the chart only extends as far back as the history does.
How does velocity relate to the burndown?
The burndown shows where the release is; velocity projects where it lands. Divide remaining points by the rolling 3-sprint average and you get the finish-line estimate that drives the release conversation — but only if scope holds still. That is why the scope-added series belongs on the same chart: a team burning 30 points a sprint while absorbing 25 new ones is barely moving toward the date, however healthy its velocity looks in isolation.
What is a cut line, and when do you use it?
When the projected finish overshoots the release date, you have three levers: move the date, add people (which rarely helps in-flight), or cut scope. The cut line is the third lever made explicit — the priority rank below which items drop out of the release. A burndown read weekly turns the cut into a calm, early decision instead of a crisis in the final week, and task completion rate against original scope keeps everyone honest about how much was actually delivered versus quietly deferred.
How do you build a release burndown in Metabase?
Sync issue data from Jira, Linear, or Azure DevOps into a database via an ETL tool, and materialize a daily
issue_snapshots model — either from the tool's changelog or from a scheduled job that copies current state each day. Chart remaining points and total scope by snapshot date, add the weekly scope-added vs. completed view, and pin both to a release burndown dashboard next to velocity.