Burn-up vs. Burn-down Charts: What's the Difference?

WHAT THIS TESTS: This question isn't a vocabulary quiz. It tests your ability to use data visualization to diagnose and communicate project health. The interviewer wants to see if you can move beyond simply reading a chart to interpreting its meaning. Can you identify scope creep? Can you accurately report on team velocity versus plan? Can you use the right tool to make delivery dates more predictable?

A GOOD ANSWER COVERS: A strong answer explains four things in order. First, define a burn-down chart: its Y-axis is work remaining (story points, hours) and its X-axis is time. Its primary purpose is to track progress toward a fixed deadline. Second, define a burn-up chart: it also has work on the Y-axis and time on the X-axis, but it features two lines: one for total scope and one for work completed. Third, compare them directly: the key difference is that a burn-up chart explicitly visualizes scope changes. A burn-down chart obscures scope creep; the line just fails to go down as expected, but the reason (slow work vs. new work) is ambiguous. Fourth, state a preference with justification, for example, preferring burn-up charts for release-level planning because they separate team velocity from scope changes, leading to more honest conversations about deadlines.

COMMON WRONG ANSWERS: The most common mistake is a junior-level description: "One line goes up, and one goes down." This shows a lack of depth. Another red flag is confusing the axes (e.g., putting scope on the X-axis). A more subtle error is claiming burn-down charts are simply "bad." They are perfectly suitable for fixed-scope, time-boxed events like a typical two-week sprint where scope change is disallowed. The worst answers fail to explain what a change in a line actually means for the project's health.

LIKELY FOLLOW-UPS: Expect questions that test your application of this knowledge. For example: "You see the total scope line on a burn-up chart jump up mid-release. What are your next steps?" (This tests stakeholder management). Or, "When would a burn-down chart be a better choice?" (Tests nuance; sprints). Or, "What other metrics do you use alongside these to get a full picture?" (Tests breadth; e.g., cycle time, lead time, cumulative flow diagrams).

ONE CONCRETE EXAMPLE: For a 3-month project initially scoped at 500 points, a burn-down chart might show 450 points remaining after the first month, suggesting the team is behind schedule. The reason is unclear. Switching to a burn-up chart clarifies the situation: it shows the team actually completed 100 points (a velocity of 100 points/month), but 50 points of new scope were added. The burn-up chart proves the issue isn't team performance but scope creep, enabling a data-driven conversation with product management about its impact on the release date.