Epic Burn-Up Charts Explained: Seeing Delivery and Scope Growth Together
A burn-up chart draws two lines — total scope and completed scope — for an epic over time. It is the simplest chart that separates “the team is not delivering” from “the epic keeps getting bigger”, and it is the one most status reports leave out.
Completed work rose every sprint — but scope rose faster, so the remaining gap grew from 18 to 23 issues.
Plot completed work against total scope: if scope climbs as fast as work completes, the epic is busy but not getting closer.
What a burn-up chart shows
An epic burn-up plots, at each sprint’s close:
- Total scope — every issue (or point) that belonged to the epic at that moment.
- Completed scope — the part of it that was done by then.
The vertical gap between the lines is the remaining work. When the lines converge, the epic is finishing. Unlike a burn-down, which plots only “remaining”, a burn-up keeps scope visible as its own line, so growth cannot hide inside a flattening curve.
Why a burn-up is more informative than percent complete
Percent complete divides one line by the other and throws both away. The same 60% can come from an epic that completed 12 issues out of 20 and hasn’t changed in months, or one that completed 36 out of 60 after doubling in size. A burn-up shows which.
Its most important use is the situation where completed work rises every sprint but the percentage barely moves because the denominator keeps growing. On a burn-up that looks like two rising lines running in parallel — delivery is steady, and so is scope growth. The right response is a scope conversation, not a performance conversation.
A flat percentage and a steadily climbing completed line mean the team is delivering — into an epic that keeps expanding.
How to build an epic burn-up from Jira
A burn-up needs history: when each issue joined (or left) the epic, and when each was completed. A standard CSV export contains neither membership history nor, reliably, completion history.
- Export the epic’s issues with Created, Resolved and Status.
- Export Epic Link / Parent changes from the changelog (Jira’s `/rest/api/3/issue/{key}/changelog`, flattened to Issue Key, Field, From, To, Changed).
- For each sprint close, replay membership: an issue is in scope if it existed and its epic at that moment was this epic.
- Count completed: done by that moment (from status history, or the Resolved date).
- Plot both series. Mark the in-progress sprint as partial.
Scope(t) = issues in the epic at time t (existing, not in a status excluded from scope)
Completed(t) = issues in Scope(t) done at time t
Remaining(t) = Scope(t) − Completed(t)Without history: do not fake it
It is tempting to draw a burn-up from current membership, assuming every issue now in the epic was always in it. That erases exactly the growth the chart exists to show and invents a history the data does not contain. If membership history is unavailable, say so, and show current scope and progress instead. A defensible minimum is still possible: issues created after a date were certainly added after it.
How to interpret changing scope
Business Profile epic
- Development complete
- 92%
- QA complete
- 68%
- Released
- 42%
Engineering completion ≠ production delivery. Development complete counts work past development; QA complete counts done and released; released counts only what reached production.
A Jira “% done” can say 92% while only 42% of the epic has reached customers — delivery has milestones after engineering.
| Pattern | What it usually means |
|---|---|
| Completed rising, scope flat | Healthy: the epic is converging |
| Completed rising, scope rising in parallel | Scope is being discovered or added as fast as work completes |
| Completed flat, scope flat | A stall — look at carryover, WIP and competing work |
| Completed flat, scope rising | The epic is growing while little finishes — needs an explicit decision |
| Scope dropping | A scope cut: work was removed or moved to another epic |
Limitations
Be explicit about what “completed” means. For an epic burn-up it is usually engineering-complete — done by the team’s workflow, whether or not it has shipped. If leadership also cares about production, report released work separately rather than redefining the completed line; otherwise a release freeze makes delivery look stalled.
Burn-ups inherit the quality of the underlying data. Issues moved between epics appear as growth in one and reduction in another; re-parented sub-tasks follow their story; and points added to existing issues after estimation change the points line without any issue joining. Read the issues behind a jump before drawing conclusions.
Apply this to your team’s delivery
Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.
Common mistakes
- Drawing history from current membership. It hides growth and fabricates the past.
- Plotting only the percentage. The two lines are the information.
- Ignoring scope reductions. A drop in scope is as informative as growth: something was cut or moved.
- Using burn-ups to compare teams. Epics differ in size, discovery and dependencies.
- Reading a single sprint’s jump as a trend. Look at several sprints and at the issues that joined.
Leadership implications and questions to ask
A burn-up changes the leadership question from “why is the team slow?” to “are we deciding what belongs in this epic?”. Scope growth is often right — discovery is real — but it should be a decision, visible to the people waiting for the epic.
Questions worth asking
- Is the epic’s scope still being discovered, or are new requirements being introduced faster than work is completed?
- Which issues joined the epic in the last few sprints, and who decided?
- What would the delivery date look like if scope stopped growing today?
- Should some of the new scope become a follow-up epic?
Example
| Sprint | Completed / Total scope | % complete |
|---|---|---|
| Sprint 14 | 12 / 47 | 26% |
| Sprint 15 | 19 / 49 | 39% |
| Sprint 16 | 27 / 53 | 51% |
| Sprint 17 | 33 / 58 | 57% |
| Sprint 18 | 39 / 61 | 64% |
Over four sprints the team completed 27 more issues. Scope grew by 14 issues (+30%). The percentage rose slowly, but the completed line climbed every sprint. The burn-up makes clear that the forecast question is about scope: at this rate of growth, the epic will not close until discovery slows.
Related metrics and how the Epic Delivery report helps
See it on your own data in the Epic delivery report.
Related guides: epic scope creep, Jira epic progress and Jira epic reporting.
The Epic Delivery report draws an epic burn-up in issues or story points when your import includes Epic Link or Parent change history, shows which issues joined or left over any period, and states “Historical epic scope data unavailable” — with current scope and progress instead — when it does not.
Frequently asked questions
- What is the difference between a burn-up and a burn-down chart?
- A burn-down plots remaining work only, so scope growth is hidden in a flattening line. A burn-up plots total scope and completed scope separately, so growth is visible as its own line.
- Can I build an epic burn-up from a Jira CSV export?
- Not from a standard export alone: it has current epic membership, not when issues joined. You need Epic Link or Parent change history from the changelog.
Related guides
Epic scope creep
How epic scope grows, why percent complete can fall while engineering delivers, how to tell a delivery slowdown from scope growth using Jira history, and what to do about it.
Jira epic progress
How to measure Jira epic progress honestly: issue-count and story-point progress, status distribution, why percent complete misleads when scope grows, and how carryover and WIP change the picture.
Jira epic reporting
How to build a high-level Jira epic report that combines progress, scope growth, sprint investment, carryover, WIP and delivery flow — and avoids the two most misleading conclusions in initiative reporting.
Initiative progress
How engineering leaders can track initiatives across sprints: the initiative → epic → story hierarchy, sprint contribution, delivery, scope, carryover and investment — from Jira data.