I sometimes read about using the burndown chart to estimate the date when the Scrum project ends. It's often described like this:

  1. estimate all features of the product and sum them up (TOTAL_STORY_POINTS)
  2. run a few sprints to get team's velocity
  3. divide TOTAL_STORY_POINTS by the velocity

If this is how it is supposed to work, then the first question that arises is: how do we estimate whole features? We can estimate small User Stories because we more or less understand the amount of work required to complete them and therefore we can roughly compare these amounts. But at the beginning of the project we only have general understanding of features our product is comprised of. We are also going to change these features as we do Customer Development. So how can we estimate the initial scope of the project in Story Points?

  • You should take a look at burn-up charts - closely related tool that is better suited to forecasting.
    – Daniel
    Nov 18, 2020 at 19:02
  • I thought burndown charts were more useful in waterfall-like methodologies. Is there a reason you're using them in Scrum?
    – Mast
    Nov 19, 2020 at 13:12

2 Answers 2


Theoretically, yes, you could use a burndown chart to estimate when all of the work in the Product Backlog would be completed. However, in practice and as you are seeing, it doesn't always work out.

Using a burndown chart to estimate completion relies on a few assumptions, such as that the Product Backlog is well-understood and is generally static. However, these are usually not true statements.

The team tends to focus its efforts on understanding the highest priority work at the top of the backlog and only minimal effort, if any at all, to understand less important work. As you move down the backlog, the work tends to be larger and less well-defined.

The Product Backlog is also frequently changing. Between the Product Owner's regular work in understanding stakeholder needs, feedback obtained in Sprint Reviews, and feedback from other sources as the product is used, the contents of the Product Backlog may change.

In practice, the idea that you can forecast the completion of an effort is inherently not Agile. In Agile, the scope is not committed to. The end of an effort is when the cost of delivering the next unit exceeds the value that it would offer. By not spending effort to define and commit to scope allows the team to respond to feedback and incorporate what is learned about the operational space of the product. I would suggest that there's not much of a difference between trying to use a burndown chart to estimate completion and big up-front planning that doesn't work in domains that have a high amount of uncertainty.


If you already have the three points you mentioned above, you don't need a burndown chart to estimate the completion date of the project. When you divide total story points by the velocity, what you get back is a number of sprints, which are time-boxed (usually) to weeks which you can then layout over a calendar and get the completion date of the project. Drawing a burndown chart will just show an ideal line between your start of the project and the same completion date you computed. Not very useful.

A burndown chart is useful not to forecast the completion date, but to show if your actual progress is happening as the progress you forecasted. You have an ideal line on the burndown, and an actual line that shows you if you are behind (above) or ahead (below) of what you ideally forecasted. Seeing that allows you to take action and correct your trajectory if you still want to deliver on the desired date.

Of course, all of this is just a bunch of ideal things you think will happen. It's a forecast, not a prediction. A lot of things turn out differently once the project is underway.

A burndown doesn't show for example if the backlog changed; you just burn through story points. A burndown doesn't show if priorities changed, or if you work now on what you thought you will work on or on something else; it just shows how many story points you burned and how many are remaining. You also assume that things stay the same once you have drawn your ideal burndown line.

But of course, things change. If people focus on building the right product, then things will change after you have done your initial forecast. If you use the burndown chart badly, some might force the team to make efforts and follow the ideal burndown line and just burn through a bunch of stories or features that should be completed by the estimated date of completion. You now basically get Waterfall with a big upfront planning and the assumption that the forecasted things are correct and any deviation from it is bad, which in reality is the other way around.

If you want to find out more about forecasting deliveries in Agile, you can start with these posts:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.