Burndown Chart Guide: How to Create, Read & Use Burndown and Burnup Charts

What Is a Burndown Chart?

A burndown chart is a visual graph that tracks remaining work against time during a sprint or project. The horizontal axis shows days (or iterations), the vertical axis shows remaining effort—measured in story points, tasks, or hours—and a single line tracks how work "burns down" from the starting total toward zero.

The term "burn down" comes from the image of work being consumed like fuel: as the team completes stories, the remaining effort burns away day by day.

Burndown charts are one of the most widely used artifacts in Scrum and agile project management. They are simple to create, easy to read, and provide immediate, objective feedback about whether a team is on track to meet a sprint goal.

Who Uses Burndown Charts?

• Scrum teams use sprint burndown charts during daily standups to gauge progress
• Project managers use release burndown charts to track overall project progress across multiple sprints
• Product owners reference them when making scope decisions mid-sprint
• Stakeholders review them for high-level status updates without needing detailed reports

Why They Matter

Without a burndown chart, teams rely on gut feeling or status meetings to judge progress. A burndown chart replaces anecdotes with data:

• See sprint progress at a glance—no status meetings required
• Detect problems early while there is still time to correct course
• Provide an objective view of the team's actual pace vs. the plan
• Give daily standups a concrete, visual discussion point
• Build a historical record that improves future sprint planning

Chart Structure

A burndown chart consists of two main lines plotted on the same axes.

The Ideal Line (Plan Line)

A straight line drawn from the total points at sprint start down to zero at sprint end. It represents the "ideal pace"—the rate at which work would need to burn down if effort were consumed perfectly evenly every day.

Example: 2-week sprint, 40 total story points
Daily burn rate = 40 / 10 business days = 4 points/day

Day 0:  40 points
Day 1:  36 points
Day 2:  32 points
...
Day 10:  0 points

The ideal line is a reference, not a target. Real work rarely follows a straight line—stories finish in batches, some days are more productive than others, and that's perfectly normal. The value of the ideal line is that it makes deviations visible.

The Actual Line

The real remaining work plotted day by day. Each time a story or task is marked Done (per the team's Definition of Done), the remaining total drops and the line moves down.

Reading the Relationship

The gap between the ideal and actual lines tells the sprint's health story at a glance.

Actual Line Position	What It Means	Suggested Action
Well below the ideal line	Ahead of schedule	Consider pulling in additional backlog items
Tracking the ideal line	On track	Continue current pace
Slightly above the ideal line	Minor delays	Discuss blockers in standup; no major changes needed
Far above the ideal line	Significantly behind	Escalate impediments; consider reducing sprint scope

How to Build a Burndown Chart Step by Step

Step 1: Gather Sprint Data

Collect the following from sprint planning before the sprint begins.

Item	Example
Sprint duration	2 weeks (10 business days)
Start date	2026-03-09 (Monday)
End date	2026-03-20 (Friday)
Total committed story points	40 points
Number of stories	8 stories
Non-working days	Weekends (Sat/Sun)

Tip: Only count stories the team has formally committed to. Stretch goals should not inflate the starting total, or the chart will show a misleading baseline.

Step 2: Draw the Ideal Line

Plot a straight line from (Day 0, Total Points) to (Last Day, 0). Use business days only—exclude weekends and holidays. If the team doesn't work Fridays, exclude those too.

Day 0  → 40 points (start)
Day 10 → 0 points  (end)
Slope  → -4 points/day

Step 3: Record Remaining Work Daily

At a consistent time each day—typically during or right after the daily standup—record the remaining story points. This is the sum of points for all stories that have not yet met the Definition of Done.

Day 0  (Mon): 40  <- Sprint start
Day 1  (Tue): 40  <- No stories completed yet
Day 2  (Wed): 35  <- 5-point story completed
Day 3  (Thu): 35  <- No completions
Day 4  (Fri): 27  <- 8-point story completed
Day 5  (Mon): 27  <- After the weekend
Day 6  (Tue): 22  <- 5-point story completed
Day 7  (Wed): 17  <- 5-point story completed
Day 8  (Thu): 10  <- 7-point story completed (split from 8 + rework)
Day 9  (Fri):  5  <- 5-point story completed
Day 10 (Mon):  0  <- Final stories completed, sprint done

Important: Only count stories as "done" when they fully satisfy the Definition of Done (code reviewed, tested, deployed to staging, etc.). Partially done stories still count toward remaining work.

Step 4: Plot the Actual Line

Plot the recorded values as a line graph alongside the ideal line. Use our Burndown Chart Generator for instant visualization, or create the chart in a spreadsheet (instructions below).

Reading Common Patterns

Burndown charts produce recognizable patterns that reveal the team's state. Learning to read these patterns is one of the most valuable skills for a Scrum Master or agile coach.

Pattern 1: Steady Descent (Ideal)

The actual line closely follows the ideal line in a smooth downward slope.

Points
40 |*
   | *·
   |  ·*
   |   *·
   |    ·*
   |     *·
   |      ·*
 0 |-------*-> Days
   Ideal(·) and Actual(*) nearly overlap

What it means: The team is consuming work at a consistent pace. Sprint planning was well-calibrated, and stories are sized appropriately for incremental completion.

Action: None required—this is the target state. Celebrate it and try to replicate the conditions.

Pattern 2: Staircase Descent

The line stays flat for multiple days, then drops sharply in a stair-step pattern.

Points
40 |****
   |    ·
   |     ****
   |         ·
   |          ***
   |             *
 0 |-----------> Days

What it means: Stories are too large. Work is progressing day to day, but nothing registers as "done" until a multi-day story is finally completed. The flat segments represent work-in-progress that hasn't yet crossed the finish line.

How to fix it:

• Break stories into smaller slices that can be completed in 1-2 days
• Use vertical slicing (thin end-to-end features) instead of horizontal slicing (all backend, then all frontend)
• Introduce sub-tasks and track them if the team needs more granular visibility
• Revisit the Definition of Done—ensure it doesn't create artificial bottlenecks

Pattern 3: Flat Start, Late Rush

Little progress in the first half of the sprint, followed by a steep drop in the second half.

Points
40 |*********
   |         ·
   |          *
   |           *
   |            *
   |             *
 0 |-----------> Days

What it means: The team spent the first half on design, environment setup, or technical investigation. Alternatively, the Definition of Done is so strict that intermediate work doesn't register until everything aligns at once.

How to fix it:

• Complete technical spikes and design work before the sprint starts (during backlog refinement)
• Clarify acceptance criteria so that partial, shippable increments can be tracked
• Split stories by layer (frontend, backend, infrastructure) to enable incremental completion
• If the pattern persists, the sprint may be too short for the team's workflow—consider whether longer sprints are appropriate

Pattern 4: Scope Creep (Line Goes Up)

Remaining work increases during the sprint instead of decreasing.

Points
40 |*
   | *
   |  **
   |    ***
   |       ****  <- Increasing
   |
 0 |-----------> Days

What it means: New work is being added mid-sprint, or original estimates were too optimistic and tasks are expanding as hidden complexity is discovered.

How to fix it:

• Enforce a no-scope-change policy during sprints (agree with the Product Owner beforehand)
• Defer new requirements to the product backlog for the next sprint
• When estimates expand, flag it immediately rather than silently absorbing more work
• Improve estimation by reviewing actuals in retrospectives

Pattern 5: Significant Work Remaining at Sprint End

A large amount of points remain on the final day.

Points
40 |*
   | ·*
   |  ·*
   |   ·*
   |    ·*
   |     ·*
20 |      ·*  <- 20 pts remain on final day
 0 |-----------> Days

What it means: The sprint was overloaded beyond the team's actual capacity. The team committed to more work than their historical velocity supports.

How to fix it:

• Base sprint capacity on the team's average velocity from the last 3-5 sprints (use our Velocity Calculator to compute this)
• Plan to roughly 80% of average velocity to leave room for unplanned work and interruptions
• Track velocity trend over time—if it's declining, investigate root causes (technical debt, team changes, unclear requirements)

Sprint Burndown vs. Release Burndown

Burndown charts come in two main flavors, each serving a different planning horizon.

Sprint Burndown

• Scope: A single sprint (1-4 weeks)
• Y-axis: Story points or tasks remaining in the sprint
• Updated: Daily
• Primary audience: Development team and Scrum Master
• Purpose: Ensure the sprint goal is achievable

Release Burndown

• Scope: An entire release or project (multiple sprints)
• Y-axis: Total remaining story points in the release backlog
• Updated: At the end of each sprint
• Primary audience: Product Owner and stakeholders
• Purpose: Forecast when the release will be ready

A release burndown helps answer the question "At our current pace, when will we finish all planned features?" It is especially useful for communicating progress to stakeholders who think in terms of deadlines rather than sprints.

Key difference: A sprint burndown should trend toward zero by sprint end. A release burndown trends toward zero over many sprints, and its slope may change as the team's velocity stabilizes or scope changes.

Beyond Sprint Burndown: Other Burndown Chart Types

While the sprint burndown is the most common format, teams often need specialized burndown views for different contexts.

Individual Burndown Chart (Per User)

An individual burndown chart — sometimes called a per user burndown chart or personal burndown chart — tracks the remaining work assigned to a single team member within a sprint. It is not a standard Scrum artifact — Scrum intentionally tracks team progress, not individual progress — but it can be useful in specific situations.

When to use an individual burndown chart per user:

• A team member is working on a largely independent workstream within the sprint
• During onboarding, to help a new member visualize their own pacing
• For self-assessment and personal productivity tracking (never imposed by management)
• When a single contributor has a fixed-scope commitment that is separate from team goals

How it works:

The chart plots only the story points or tasks assigned to one person, with an ideal line based on their expected availability (accounting for meetings, part-time allocation, etc.).

Individual Burndown - Alice (Sprint 7)
Points
12 |*
   | ·*
   |  ·*
   |   ·**
   |    ·  *
   |     ·  *
 0 |------·--*-> Days

Important caution: Never use individual burndown charts for performance evaluation or comparison between team members. This undermines the collaborative culture that makes Scrum effective. The chart is a personal planning tool, not a management reporting tool.

Cross-Team Burndown Chart

A cross-team burndown chart aggregates remaining work across multiple teams working toward a shared goal (e.g., a product release or a large initiative). It is used at the program or portfolio level.

When to use it:

• Multiple Scrum teams are contributing to the same release or epic
• A program manager needs visibility into overall progress without diving into individual team sprints
• PI (Program Increment) planning in SAFe environments

How it works:

Sum the remaining story points from all contributing teams and plot them against the release timeline. Each team's velocity contributes to the overall burn rate.

Cross-Team Burndown - Q2 Release
Points
200 |*
    | ·*
    |  ·*
    |   ·**
    |    ·  *
    |     ·  **
  0 |------·----*-> Sprints (1-6)

Teams: Alpha (vel: 40), Beta (vel: 35), Gamma (vel: 45)
Combined velocity: ~120 pts/sprint

Key considerations:

• Normalize story points across teams before aggregating (teams may size differently)
• Scope changes at the release level are common — consider supplementing with a cross-team burnup chart or a release burnup chart that makes scope changes explicit (examples are shown later in this guide under "Burnup Chart Examples by Level")
• For multi-team programs, a cross-team burnup is usually preferred over a cross-team burndown because it exposes when epics are added, descoped, or re-estimated
• Update the chart at the end of each sprint, not daily

Kanban Burndown Chart

Traditional burndown charts are designed for time-boxed sprints. In Kanban, work is continuous and there is no sprint boundary. However, a modified burndown can still be useful when Kanban teams set delivery targets or Service Level Expectations (SLEs).

When to use it:

• A Kanban team has committed to delivering a specific set of items by a target date
• A team running Kanban wants to track progress toward a quarterly goal or milestone
• During a fixed-scope project managed with Kanban flow

How it works:

Instead of a sprint, the X-axis represents the calendar period until the target date. The Y-axis shows the remaining items (or story points) in the commitment. The ideal line runs from the total at the start to zero at the target date.

Kanban Burndown - March Delivery Target
Items
15 |*
   | ·*
   |  ·**
   |   ·  *
   |    ·  **
   |     ·   *
 0 |------·---*-> Weeks (1-4)

Alternative for Kanban: Many Kanban practitioners prefer a cumulative flow diagram (CFD) over a burndown chart, as CFDs visualize WIP limits, lead time, and throughput simultaneously. If your team does not set periodic delivery targets, a CFD is likely a better fit.

Burndown Chart vs. Burnup Chart

A common question is whether to use a burndown or burnup chart. The answer depends on how much scope changes during the project.

Burndown Chart

• Tracks remaining work (starts high, trends toward zero)
• Simple and intuitive
• Limitation: When remaining work drops, you can't tell whether tasks were completed or removed

Burnup Chart

• Tracks completed work on one line and total scope on another
• Two lines: scope line (total work) and done line (completed work)
• Advantage: Scope changes are visible—if the scope line rises, you can see new work being added

When to Use Which

Situation	Recommended Chart
Stable sprint scope (no mid-sprint changes)	Burndown
Frequent scope changes	Burnup
Communicating to stakeholders unfamiliar with agile	Burndown (simpler)
Release-level tracking with evolving requirements	Burnup
Daily standup discussions	Either works

Practical tip: Many teams maintain a sprint burndown (simple, daily) alongside a release burnup (captures scope changes across sprints). The two charts complement each other.

Burnup Chart Examples by Level (Release, Kanban, Initiative, Cross-Team)

A burnup chart tracks two lines — completed work (the "done" line) and total scope (the "scope" line) — which makes scope changes explicit. Different levels of planning call for different burnup chart configurations. Below are four common burnup chart examples teams use in practice, with when-to-use guidance for each.

Release Burnup Chart Example

A release burnup chart spans an entire release — typically 3–6 months or 4–8 sprints — and is the most common burnup chart in agile programs. It answers "When will this release be ready, and how much has scope changed since we started?"

Release Burnup — Q2 2026 (6 sprints)
Story Points
200 |                    ----- Scope line (180 → 200 after S3)
    |           -----
180 |-----
    |              *   <- Scope addition visible here
160 |           *
    |       *                                    * <- Done line
120 |    *
    |  *
 40 |*
  0 |————————————————————————————> Sprints (1–6)
     S1   S2   S3   S4   S5   S6

• Scope line: Total committed story points for the release, updated whenever the backlog changes
• Done line: Cumulative completed story points, updated at the end of each sprint
• Key insight: When the scope line bumps up at Sprint 3, a release burndown chart would have shown the same move ambiguously. A release burnup chart makes it clear that new work was added rather than the team slowing down.

When to use a release burnup chart:

• Long-running releases where scope evolves across multiple sprints
• Stakeholder reporting where "are we adding more work?" is a common question
• Forecasting release dates based on velocity trend and remaining scope
• Any release where a simple release burndown would hide scope creep

To generate a release burnup chart quickly, you can extend our Burndown Chart Generator data model by plotting cumulative completed points and a separate scope line in a spreadsheet.

Kanban Burnup Chart Example

Kanban teams don't have sprints, but a burnup chart is still useful when a Kanban team commits to delivering a fixed set of items by a target date — for example, a quarterly roadmap commitment, a customer-facing launch, or a compliance deadline.

Kanban Burnup — March Launch (4 weeks)
Items
30 |                      ----- Scope line (25 → 30 after W2)
   |               -----
25 |-----
   |                                          * <- Done line
20 |
   |                                *
15 |                     *
   |              *
10 |         *
   |     *
 5 |  *
 0 |—————————————————————> Weeks (1–4)
    W1   W2   W3   W4

• X-axis: Calendar weeks instead of sprints (or even days for short-cycle teams)
• Scope line: Items (or story points) committed to the launch, adjusted as requirements firm up
• Done line: Items that have moved to the "Done" column on the Kanban board
• Pair with a CFD: Kanban teams often display this burnup alongside a cumulative flow diagram (CFD) so they can also see WIP limits and lead time at the same time.

When to use a Kanban burnup chart:

• Fixed-scope launches with a hard deadline
• Customer commitments where stakeholders want a visual of "how much is left"
• Non-sprint teams tracking milestone progress toward a release date
• Teams new to burnup charts who want a simple introduction before moving to release or initiative burnups

If your Kanban team does not make date commitments, a standalone cumulative flow diagram is usually enough and no burnup chart is necessary.

Initiative Burnup Chart Example

An initiative burnup chart tracks a cross-cutting initiative that may span multiple releases and multiple teams — for example, a platform migration, a compliance effort, a major SDK upgrade, or a strategic OKR. It operates at the portfolio or program level, above individual release burnups.

Initiative Burnup — Platform Migration (6 months)
Story Points
500 |                              ----- Scope line (stable)
    |--------------------------
400 |                                                 *
    |
300 |                                        *
    |                               *
200 |                      *                   <- Done line
    |             *
100 |      *
    |  *
  0 |—————————————————————————————> Months (1–6)
     M1   M2   M3   M4   M5   M6

• Time unit: Months or Program Increments (PIs) instead of sprints
• Scope line: Total estimated effort for the initiative, which may evolve as discovery work reveals hidden complexity
• Done line: Cumulative story points completed across all contributing teams
• Key insight: If the scope line stays roughly flat while the done line rises steadily, the initiative is healthy. A widening gap — or a done line that flattens — signals the initiative has stalled and needs executive attention.

When to use an initiative burnup chart:

• Strategic programs with executive visibility (quarterly business reviews, board reports)
• Multi-team coordination where individual sprint burndowns are too fine-grained
• OKR or strategic objective tracking where "percent complete" must be justified with data
• Migration or modernization projects that run for 2+ quarters

An initiative burnup chart is often the highest-level artifact a program manager maintains. It is normally updated monthly or at each PI boundary, not weekly.

Cross-Team Burnup Chart Example

When several Scrum teams contribute to a shared release or program, a cross-team burnup chart aggregates their progress and exposes scope changes across the whole program. It is especially common in SAFe Program Increment (PI) planning and in any multi-team release where a single cross-team burndown would hide scope creep.

Cross-Team Burnup — PI 2026-Q2 (3 teams, 6 sprints)
Story Points
360 |                              ----- Scope line (320 → 360)
    |              --------
320 |--------
    |
240 |                                              * <- Done line
    |                                    *
160 |                          *
    |                 *
 80 |        *
    |  *
  0 |———————————————————————————————> Sprints (1–6)
     S1   S2   S3   S4   S5   S6

Contributing teams:
  Alpha (velocity ~40 pts) + Beta (~35 pts) + Gamma (~45 pts)
Combined velocity: ~120 pts/sprint

• Aggregation: Sum of committed scope and completed points across all contributing teams
• Scope line: Total committed work for the PI, adjusted during PI planning and inspection events
• Done line: Combined completions across Alpha, Beta, and Gamma teams
• Caveat on story point normalization: Each team's "3 points" may represent different effort. Normalize (for example, convert to a common reference story) before aggregating, or the combined numbers will mislead.

When to use a cross-team burnup chart:

• SAFe PI tracking and program-level release management
• Programs with 2+ Scrum teams contributing to the same release or epic
• Large releases where a cross-team burndown alone would hide scope changes
• Stakeholder reporting where "did we add work or did teams slow down?" is a common question

For most cross-team programs, a cross-team burnup is preferred over a cross-team burndown because program scope rarely stays perfectly stable — epics get added, descoped, or re-estimated, and a burnup chart's explicit scope line makes those changes visible.

Building a Burndown Chart in a Spreadsheet

You don't need specialized software. A spreadsheet (Google Sheets, Excel) works perfectly.

Data Table Layout

Set up a table with four columns:

Date	Business Day	Ideal Remaining	Actual Remaining
3/9	Day 0	40	40
3/10	Day 1	36	40
3/11	Day 2	32	35
3/12	Day 3	28	35
3/13	Day 4	24	27
3/16	Day 5	20	27
3/17	Day 6	16	22
3/18	Day 7	12	17
3/19	Day 8	8	10
3/20	Day 9	4	5
3/21	Day 10	0	0

Formulas

For the Ideal Remaining column, use this formula (assuming total points are in cell B1 and the number of business days is in cell B2):

Ideal Remaining = Total Points - (Total Points / Business Days) * Day Number

In Google Sheets: =$B$1 - ($B$1 / $B$2) * A3 (where A3 is the day number).

Charting Steps

1. Select the "Business Day", "Ideal Remaining", and "Actual Remaining" columns
2. Insert a line chart
3. Style the ideal line as dashed and the actual line as solid
4. Set the Y-axis minimum to 0 and maximum to the total points
5. Add a chart title: "Sprint Burndown - Sprint [Number]"
6. Optionally add data labels to the actual line for quick reference

Want to skip the spreadsheet setup? Use our Burndown Chart Generator to create a chart instantly—just enter your sprint data and get a downloadable chart.

Burndown Charts in Popular Tools

Jira

Jira provides a built-in sprint burndown chart for Scrum boards. Navigate to your board, click Reports, and select Burndown Chart. Jira calculates remaining work automatically based on story point fields and sprint assignments.

Key configuration tips:

• Ensure every story has a story point estimate before the sprint starts
• Use the "Remaining Estimate" field for task-level tracking
• Jira's burndown updates in real time as stories move to "Done"

Azure DevOps

Azure DevOps includes a sprint burndown widget in its Analytics views. Add it to your team dashboard and configure it to track story points, tasks, or remaining hours.

Trello (with Power-Ups)

Trello doesn't have a native burndown chart, but Power-Ups like Corrello or Burndown for Trello add this functionality by tracking card completion over time.

Free Online Tools

If your team doesn't use a dedicated project management tool, our Burndown Chart Generator lets you create and download a burndown chart in seconds. Enter your sprint dates, total points, and daily actuals to get an instant visualization.

Using Burndown Charts in Daily Standups

The burndown chart should be visible during every daily standup. Display it on a shared screen or TV dashboard so the team can reference it while discussing progress.

What to Discuss

• Actual vs. ideal: If the actual line is above the ideal line, ask what's causing the delay. Is it a blocker? A story that's larger than estimated?
• Extended flat periods: A flat line for 2+ days suggests a blocker or a story that's too large to complete incrementally
• Sudden drops: A large drop usually means a big story was completed—verify it meets the Definition of Done
• Upward movement: Any increase signals scope creep that needs immediate attention

Ground Rules for Using the Chart

• The chart is a team health check, not an individual performance metric
• When behind schedule, discuss "What can we do?" not "Whose fault is it?"
• Chart updates are a shared team responsibility—don't assign one person to maintain it
• Never use the chart to pressure the team into cutting corners on quality

Common Mistakes and How to Avoid Them

Mistake 1: Updating the Chart Inconsistently

Some teams only update the chart every few days or forget entirely. This makes the chart unreliable and defeats its purpose.

Fix: Assign a specific time for updates (e.g., "right before daily standup") and automate the update through your project management tool whenever possible.

Mistake 2: Tracking Hours Instead of Story Points

Tracking remaining hours can lead to micromanagement and doesn't account for the non-linear nature of knowledge work.

Fix: Track story points at the story level. If you need time-level tracking, use it for individual tasks within stories—not as the primary metric on the burndown.

Mistake 3: Not Adjusting for Team Capacity

If a team member is on vacation or called away for a production incident, the team's effective capacity decreases. If the burndown doesn't account for this, the ideal line becomes unrealistic.

Fix: Adjust the total committed points during sprint planning using our Sprint Calendar to factor in holidays, vacations, and planned absences.

Mistake 4: Ignoring the Chart When It Shows Problems

Some teams treat the burndown as a ritual artifact—they update it daily but never actually discuss or act on what it reveals.

Fix: Make the burndown a centerpiece of standup discussions. When the chart shows a widening gap, treat it as a prompt for immediate problem-solving, not something to address "later."

Mistake 5: Using Burndown Charts to Compare Teams

Burndown charts reflect a single team's progress against its own plan. Comparing burndown charts across teams with different contexts, capacities, and story sizing practices is misleading.

Fix: Use burndown charts for intra-team improvement. For cross-team reporting, use normalized metrics like velocity trends or delivery predictability.

Limitations of Burndown Charts

Burndown charts are valuable but have genuine blind spots that teams should understand.

Scope Changes Are Invisible

A drop in remaining work could mean "tasks completed" or "tasks removed from the sprint." Similarly, scope additions are only visible as an upward bump—you can't distinguish new work from re-estimated work. For projects with frequent scope changes, supplement with a burnup chart that tracks scope and completion separately.

Quality Is Not Reflected

A smoothly descending chart doesn't guarantee quality. Teams under pressure might mark stories as "done" without thorough testing or code review. Always pair the burndown with a strong Definition of Done that includes quality gates.

The "Why" Is Missing

The chart shows what is happening (ahead, behind, on track) but not why. When the chart signals a problem, the team needs conversation to identify root causes. The chart is a starting point for discussion, not a replacement for it.

Individual Contribution Is Not Visible

Burndown charts show team-level progress only. They intentionally do not show who completed what. This is a feature, not a bug—it reinforces collective ownership. If you need individual tracking, use a separate tool and keep it separate from the burndown.

Frequently Asked Questions

What is the difference between a burndown chart and a velocity chart?

A burndown chart tracks remaining work within a single sprint—it answers "Are we on track to finish this sprint?" A velocity chart tracks the total story points completed across multiple sprints—it answers "How much work does this team typically complete per sprint?" Use both: the burndown for daily sprint management, and velocity for long-term planning. You can calculate your team's velocity with our Velocity Calculator.

How do I handle stories that are added mid-sprint?

If a story is added mid-sprint, the remaining work total increases and the actual line on the burndown moves up. This is the correct behavior—it makes scope changes visible. To avoid misleading charts, enforce a policy of minimizing mid-sprint additions. If additions are unavoidable, consider removing an equal amount of uncommitted work.

Should the burndown track story points, tasks, or hours?

Story points are the most common choice because they represent the relative size of work without implying a specific duration. Tasks work well for teams that don't use story points but break work into small, consistently-sized pieces. Hours are the least recommended because they encourage micromanagement and are difficult to estimate accurately. Choose the unit that your team already uses for sprint planning.

What if the burndown chart always shows a staircase pattern?

A persistent staircase pattern means stories are consistently too large for daily completion. The fix is to improve story splitting: aim for stories that can be completed in 1-2 days. Use techniques like vertical slicing (thin end-to-end features) or splitting by acceptance criteria to create smaller, independently completable units.

How do I read a burndown chart for a remote team?

Reading the chart is the same regardless of whether the team is co-located or remote. The key difference is visibility: ensure the chart is displayed on a shared digital dashboard (not hidden in a tool that requires login). During remote standups, share the chart on screen and walk through it briefly. Automated daily chart updates sent to Slack or Teams channels also help.

Can I use a burndown chart for Kanban?

Traditional burndown charts are designed for time-boxed sprints with a fixed scope. In Kanban, where work is continuous and scope is fluid, a cumulative flow diagram (CFD) is usually more appropriate. However, if your Kanban team sets WIP limits and works toward periodic delivery targets, a modified burndown chart can still be useful.

What is a good burndown chart update frequency?

Daily is the standard and recommended frequency. Updating less frequently (e.g., every 2-3 days) reduces the chart's ability to surface problems early—which is its primary purpose. If daily updates feel burdensome, automate them through your project management tool rather than reducing the frequency.

What is a release burnup chart example, and how does it differ from a release burndown?

A release burnup chart tracks completed work and total scope as two separate lines across an entire release (typically 3–6 months). A release burndown only tracks remaining work as a single line. The burnup's key advantage is that scope changes are visible — if new work is added mid-release, the scope line rises, whereas a burndown would just show remaining work bumping up ambiguously. For any release where scope might change, a release burnup chart is almost always the better choice. A visual example is shown earlier in this guide under "Burnup Chart Examples by Level".

What is an individual burndown chart per user, and when should I use one?

An individual burndown chart — also called a per user burndown chart — tracks the remaining story points or tasks for a single team member within a sprint, rather than for the entire team. It is not a standard Scrum artifact and should never be used for performance evaluation or cross-member comparison. Valid use cases include self-assessment by an individual contributor, onboarding new team members, or tracking a largely independent workstream that runs in parallel with team goals. For all team-level reporting, use a standard sprint burndown chart instead.

Should I use a cross-team burndown or a cross-team burnup chart?

For multi-team programs and SAFe PI tracking, a cross-team burnup chart is almost always preferred over a cross-team burndown. Programs rarely have perfectly stable scope — epics get added, descoped, or re-estimated over the course of a release — and a burnup's explicit scope line makes those changes visible. A cross-team burndown can mask scope creep by folding it into the single remaining-work line. If your program has truly fixed scope and a hard deadline, a cross-team burndown is acceptable; otherwise default to a cross-team burnup.

What does an initiative burnup chart show, and how often should I update it?

An initiative burnup chart plots cumulative completed story points against total initiative scope, typically over months or Program Increments rather than sprints. It is used for strategic, cross-team programs like platform migrations, compliance initiatives, or major modernization efforts. A healthy initiative shows a steadily rising done line against a roughly flat scope line. A widening gap between the two — or a done line that goes flat — signals the initiative has stalled and needs executive attention. Update an initiative burnup chart monthly or at each PI boundary, not weekly: at the initiative level, shorter update cycles add noise without new insight.

What is a kanban burnup chart example, and do I need one if I already have a cumulative flow diagram?

A Kanban burnup chart example plots completed items and committed scope across calendar weeks (instead of sprints), targeting a fixed delivery date. It works well for launches, quarterly roadmap commitments, or customer deadlines. If your Kanban team already makes date commitments, pair the burnup chart with a cumulative flow diagram (CFD) to also see WIP limits, lead time, and throughput. If your Kanban team does not make date commitments and flows work continuously, a CFD alone is usually enough and you do not need a burnup chart.

Summary

A burndown chart is one of the simplest and most effective tools in agile project management. By plotting remaining work against time, it gives teams—and anyone watching—immediate clarity about sprint progress. The ideal line sets the benchmark, the actual line tells the truth, and the gap between them drives action.

Learn to read the five common patterns: steady descent (healthy), staircase (stories too large), flat start with late rush (front-loaded investigation), scope creep (line goes up), and overcommitment (significant work remaining at sprint end). Each pattern points to a specific improvement action.

For sprint-level tracking, use a burndown chart. For releases, Kanban launches, cross-team programs, and multi-quarter initiatives where scope evolves, use a burnup chart — the release burnup, Kanban burnup, initiative burnup, and cross-team burnup examples above are the four most common configurations. Whether you build your chart in a spreadsheet, Jira, or our free Burndown Chart Generator, the key is consistency: update it on a cadence that fits the level (daily for sprints, per sprint for releases, monthly for initiatives), discuss it regularly, and use it as a catalyst for team improvement — never as a tool for blame.