{"id":12292,"date":"2025-11-10T06:30:00","date_gmt":"2025-11-10T05:30:00","guid":{"rendered":"https:\/\/deltaagile.com\/?p=12292"},"modified":"2026-02-23T11:26:45","modified_gmt":"2026-02-23T10:26:45","slug":"burnup-vs-burndown-chart","status":"publish","type":"post","link":"https:\/\/deltaagile.com\/en\/burnup-vs-burndown-chart\/","title":{"rendered":"BURNUP vs. BURNDOWN CHART"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Burnup and burndown charts are visual tools for displaying completed work and work remaining in the Product Backlog<\/a>.<\/p>

Some teams use both. In my opinion, this is unnecessary, as the burndown chart is less flexible and can be fully replaced by the burnup. Let’s see why. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

A typical burndown looks like this:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Burndown\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

For the same velocity, a burnup would look like this:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Burnup\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

To estimate the amount of remaining work, we had to add a line representing the backlog size to the burnup. In the burndown, the x-axis serves this purpose. <\/p>

The amount of work in the product backlog rarely remains the same<\/strong> across iterations. How do we show such a change in scope on the chart? <\/p>

On a burnup<\/strong> chart, this is simple. We adjust the backlog line: <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Burnup\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

On a burndown chart, however, showing additional scope is a bit more difficult. Some teams subtract the added scope from the work already done (image). Such a representation is quite bad for team morale. Members quickly get the feeling that they’re regressing despite all their efforts. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Burnup\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Another way to visualize additional scope on a burndown chart is to move the scope line into the negative. This is usually shown in one of the following ways (line or columns). <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Burndown\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Burndown\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

None of the above methods of adjusting the burndown chart are practical. The burnup chart, due to its design, avoids these problems.<\/span><\/strong> An additional bonus is that we can develop the burnup into a Cumulative Flow Diagram (CFD)<\/strong> without any special complications, which we looked at in more detail in this article<\/a>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"CFD\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

CFD diagrams<\/a> are a useful Lean tool that provide developers and the Scrum Master<\/a> with insight into the flow of functionality through the development process.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Scenarios and Forecasting<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The burnup chart can also be used to predict project duration with different scenarios. Based on the team’s velocity, we can draw projections<\/strong> that show possible development scenarios: <\/p>

  • Realistic forecast<\/strong> is based on the average speed from past iterations and is equivalent to the linear trend of velocity from previous iterations,<\/p><\/li>

  • Optimistic forecast<\/strong> assumes that the team will work faster in the next period (factor 1.15 on the chart),<\/p><\/li>

  • Pessimistic forecast<\/strong> shows what happens if progress is slower (factor 0.85 on the chart).<\/p><\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    In the chart below, we are at the beginning of the 6th iteration and want to prepare projections based on positive or negative factors we anticipate in the future. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Burnup\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    This way, we don’t get one “exact” completion date, but a range of possible dates. This is much more useful for the Product Owner and stakeholders, as they can realistically assess risks and make decisions based on multiple scenarios. <\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Factors that can influence the value of the modifier for optimistic or pessimistic variants could include, for example: <\/p>

    • planned vacations and training<\/li>
    • anticipated sick leaves (based on past trends) during virus seasons<\/li>
    • completion of onboarding new team members and their full engagement in the project<\/li>
    • arrival of new team members<\/li>
    • planned start of using TDD<\/li>
    • splitting the team into two smaller ones working on the same product<\/li>
    • hiring a Scrum Master<\/li>
    • planned work optimizations identified in the Sprint Retrospective<\/li>
    • etc.<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Burnup\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t

      Conclusion<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t

      The burnup chart is not just an alternative display of the burndown, but it brings some important advantages. The biggest is that it clearly separates team speed from scope changes. If the scope increases, we see this as a shift in the upper line, and if the team works slower, this is shown by the slope of the lower line. Additionally, the burnup allows for easy communication with stakeholders, as it’s immediately clear how much work has been done and how the goal is changing. Such a display is often psychologically more encouraging, as we see progress as growth and achieved goals, rather than counting down remaining work. <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

      Burnup and burndown charts are visual tools for displaying completed work and work remaining in the Product Backlog. Some teams use both. In my opinion, this is unnecessary, as the burndown chart is less flexible and can be fully replaced by the burnup. Let’s see why. A typical burndown looks like this: For the same […]<\/p>\n","protected":false},"author":1,"featured_media":12250,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[70],"tags":[],"class_list":["post-12292","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tools"],"_links":{"self":[{"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/posts\/12292","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/comments?post=12292"}],"version-history":[{"count":3,"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/posts\/12292\/revisions"}],"predecessor-version":[{"id":13307,"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/posts\/12292\/revisions\/13307"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/media\/12250"}],"wp:attachment":[{"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/media?parent=12292"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/categories?post=12292"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/deltaagile.com\/en\/wp-json\/wp\/v2\/tags?post=12292"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}