task-ops
The burndown chart for last sprint shows a line that barely moves for eight days and then drops almost to zero on the final afternoon. Everyone who worked that sprint knows the work was spread fairly evenly across it. The chart is not lying, but it is not describing the sprint either. It is describing the moments when items were closed, which is a different thing.
Most complaints about the burndown chart in Jira turn out to be one of four specific mismatches between what the chart plots and what the team assumed it plots. None of them require a plugin to fix. They require knowing which number the vertical axis is showing, and what Jira does and does not count.
Two facts set the frame for everything else.
First, the chart is scoped to one board type. Atlassian's documentation states plainly that the Burndown Chart only applies to scrum boards. A team working on a kanban board has no sprint boundary for the chart to measure between, and looks to a cumulative flow diagram or a control chart instead.
Second, the vertical axis is not fixed. The vertical axis represents the estimation statistic configured for the board, which means the same sprint can produce two different looking charts depending on a board setting made once, possibly years ago, possibly by somebody who has left. Before arguing about the shape of a line, it is worth opening the chart and reading which statistic is selected.
The chart also draws a grey guideline, the straight path from the starting total down to zero across the sprint. It is a reference, not a target. Real work does not arrive in equal daily slices, and a team whose actual line hugs the guideline exactly is usually a team closing items to match the chart.
One detail catches people out here. If the guideline does not appear at all, the cause is documented: the sprint may have been started before any work items were assigned to it. The chart has no opening total to draw from, so there is nothing to slope down from.
Each of these is a setting or a counting rule, not a team habit, and each produces a recognisable distortion.
Story points on subtasks do not count. Atlassian documents this directly: Story Points on subtasks are not included in the Burndown Chart, and only Story Points on parent tasks are included. For a team that estimates at the subtask level and leaves the parent unpointed, the chart will show a starting total far below the work actually committed, and items will appear to burn down in a single jump when the parent closes.
Scope change from subtasks depends on a setting. When remaining estimate tracking is enabled and a subtask is added to an item in an active sprint, that subtask is treated as scope change, and the scope change is indicated in the chart. With that tracking disabled, the same addition is not indicated. Two teams can therefore do exactly the same thing and get charts that tell opposite stories about whether the sprint grew.
The chart records closure, not progress. An item worth eight points contributes nothing to the line until its status reaches the done column, however much of it is built. Teams that carry several large items in parallel will always produce a flat line followed by a cliff, and the cliff is an artifact of item size rather than a sign of a last minute rush.
Estimates are edited mid sprint. Changing an estimate on an item inside a running sprint moves the total, and the line reflects the edit rather than the work. This is why a burndown occasionally goes up on a day when the team shipped something.
The chart is most useful as a prompt for a specific question rather than as a score.
| Shape | Usual cause | What to check first |
|---|---|---|
| Flat, then a cliff at the end | Items too large to close before the final days | Item sizes, and whether estimates sit on parents |
| Line rises during the sprint | Scope added, or estimates revised upward | Scope change indicators and the item history |
| Regular steps, close to the guideline | Healthy flow with items of similar size | Nothing. This is what it looks like when it works |
| Drops to zero well before the end | Sprint underfilled, or items closed in advance of review | Definition of done, and how much was pulled in |
| No line at all for the first days | Sprint started before items were assigned | Whether the guideline is missing for the same reason |
The one shape that should always be investigated is the rising line, because it is the only one that says something changed after the commitment was made. Everything else is a question about sizing or about the definition of done.
The chart lives under reports. Select the relevant space from the sidebar, open the Reports tab, then open the Burndown Chart. The dropdown menus there allow a different sprint or a different estimation statistic to be selected, which is the fastest way to see how much of the chart's shape comes from the setting rather than from the work.
Three decisions determine whether the output is worth reading.
Estimate at one level and be consistent about it. Since subtask points are excluded, a team estimating on subtasks needs the parent pointed as well for the chart to open at the right total. Deciding to estimate only at the parent level is usually the simpler path, because it removes the double counting question entirely.
Pick the statistic and leave it alone. Story points and remaining estimate answer different questions. Story points measure relative size agreed by the team, and they do not change as work progresses, so the line only moves when items close. Remaining estimate measures time still believed necessary, and it moves as people update it, so the line moves daily but depends on everyone keeping their hours current. Neither is more honest. Switching between them mid quarter makes sprints incomparable.
Fix the definition of done before blaming the chart. A burndown is a record of items reaching done. If done means merged for one person and released for another, the line is measuring an inconsistency rather than progress.
A single burndown is nearly worthless. The value appears when four or five of them sit side by side and a pattern shows up, and that only works if the conditions stay still.
Four things have to hold constant for the comparison to mean anything. The estimation statistic has to be the same, because story points and remaining estimate produce different shapes from identical work. The sprint length has to be the same, because a three week sprint has a naturally flatter early slope than a one week sprint. The definition of done has to be the same, since the line is a record of items reaching done and nothing else. And the team has to be roughly the same size, because half the point of the comparison is spotting when capacity changed.
When those hold, the chart earns its keep in a way no single sprint can show. A team that produces a cliff at the end of four consecutive sprints has an item sizing problem, not four separate bad weeks, and that is a concrete thing to fix in the next planning session. A team whose line rises in three sprints out of four has a commitment problem upstream, and no amount of internal discipline will flatten it.
It also pays to write down, briefly, what happened outside the chart in each sprint. A two day outage, a public holiday, two people onboarding: these produce chart shapes that look like poor execution and were nothing of the kind. Without that note, the next quarter's retrospective will compare a holiday sprint against a normal one and draw a conclusion from it.
One caution about velocity. Averaging completed points across recent sprints is a reasonable planning input, and it stops being reasonable the moment the number becomes a target. Points are a team's private unit of relative size. When they are compared between teams or set as a goal, they inflate, and both the velocity figure and every burndown built on it stop describing anything real.
A burndown compresses a sprint into one number per day, and three important things do not survive that compression.
It carries no dates other than the sprint boundary. A demo on the Wednesday, a customer call, a release freeze and a person away for three days are all invisible, even though they are usually the reason a sprint went the way it did.
It carries no dependencies. Two items where one blocks the other look identical to two independent items of the same size, right up until the blocking one slips.
It carries no names. A sprint where three of the five items rely on the same person has the same burndown as a sprint where the work is spread across the team, and only one of those sprints is robust.
This is why the chart is best read next to something that shows the sprint laid out in time rather than summed per day. Teams that keep a board and a timeline view of the same work in one place can see the blocked pair and the person carrying three items without building a second report. A setup where the board, the timeline and the calendar are the same data removes most of the reconciliation work that goes into explaining a burndown after the fact.
Some work does not have the shape a burndown assumes. Continuous streams of similar sized requests, support queues, and anything without a fixed commitment window are measured better by throughput and cycle time, because there is no total to burn down. Forcing a sprint boundary onto that work produces a chart that looks bad every time without ever suggesting an action.
Long running projects with hard external dates are the other case. A burndown tells nothing about whether the sequence of work fits between now and the delivery date, which is what stakeholders on those projects are actually asking. A dependency aware timeline answers that, and it answers it before the sprint rather than after. For teams juggling both modes, keeping the sprint view and the delivery timeline in one tool avoids maintaining two versions of the truth.
Open last sprint's chart and read the estimation statistic in the dropdown before reading the line. If the starting total is lower than what the team believes it committed, the estimates are on subtasks and the parents are unpointed, and that single fix will change every chart from here on.
After that, stop reading the chart alone. Put the sprint's dated commitments and the people carrying each item next to it, whether that means a second view in the same tool or a deliberate five minutes in the daily meeting. Teams that want the board, the timeline and the calendar over one set of items can see how Pinateca sets that up before moving anything.
The most common cause is that estimates sit on subtasks. Atlassian documents that story points on subtasks are not included in the chart and only points on parent tasks count. Move the estimate to the parent item, or estimate only at parent level, and the opening total will match the commitment.
Something was added or re estimated after the sprint started. Subtasks added to items in an active sprint are treated as scope change when remaining estimate tracking is enabled, and editing an estimate mid sprint moves the total directly. The item history will show which of the two happened.
No. The documentation states that the Burndown Chart only applies to scrum boards, because the chart needs a sprint with a start, an end and a fixed opening total. Continuous work is measured with a cumulative flow diagram, throughput, or cycle time instead.
Not necessarily. The guideline is a straight reference from the opening total to zero, and real work rarely arrives in equal daily slices. A line that tracks the guideline precisely is often a sign that items are being closed to match the chart rather than when they are genuinely finished.
They answer different questions. Story points only move when an item closes, so the chart is honest but coarse. Remaining estimate moves daily but only stays accurate if everyone updates their hours. Pick one, keep it for several sprints, and compare sprints only within the same setting.