Release burnup chart (Scrum)


Scrum Release Burnup Chart shows the cumulative amount of work done in each sprint in the context of a release and rises towards the target, the release scope yet to be done. It helps to answer the following questions:

  • How the team progresses toward the target, delivery of the release?

  • When the team is supposed to deliver the release?

The main feature of the burnup chart is the ability to forecast how long it will take to complete the work remaining. Based on the team’s velocity, you can get optimistic, realistic, and pessimistic forecasts of when the planned scope is going to be delivered:

Chart analysis


Let’s analyze the chart above. This burnup chart is built for team “Omega,” which follows the Scrum process and is currently working on their target to release version 2.0 of a software product.

By default, Scrum Team Burnup Chart is built for all Jira issues in the specified Jira Scrum Board, which in most cases doesn’t make sense.

We recommend reducing the target scope by choosing release, epic, or writing your own JQL. Check the configuration article for more details.

For the burn-up chart, we see that the total scope size of version 2.0 is 148 story points (you can also use hours or issue count).

The team works in 1-week sprints (the information is taken from Jira Scrum Board). You can check team’s velocity for each sprint by hovering over data points on the chart:

We see that in Sprint 2 the team delivered 13 story points. This information is taken into account when building a forecast.

At the end of Sprint 2 the total completed scope size of version 2.0 was 29 story points.


Let’s check the forecast for the case of team’s average velocity:

Forecast based on average velocity

We see that if the team keeps up with their average velocity of 16 story points, it will take 7 more sprints to complete the scope of version 2.0. The current sprint is “Sprint 3”, so the team will reach the target in “Sprint 10”.

The total scope size that the team is expected to deliver in Sprint 10 is 160 story points, leaving some room for scope fluctuation because version 2.0 scope size is 148 story points.

The same logic applies if we take into analysis the maximum and minimum team’s velocity. If we are optimistic, we may expect for version 2.0 to take 6 more sprints; if we take the pessimistic scenario, we should expect the delivery to take 8 more sprints.

What-if scenarios

What-if scenario for a given velocity

Let’s model what would be the delivery date if team Omega’s velocity is 25 story points. Here is how you configure this:

From the chart below, we see that the team will be able to complete version 2.0 in 4 sprints:

What-if scenario for a given delivery date

Suppose you specify the target date by which the team should deliver the planned scope. In that case, the burnup chart will calculate the needed velocity. Here is how you configure this:

The target date is set for July 20th. From the chart below, we see that in such a case, the velocity must be equal to 25 story points:

What-if scenario for a given amount of work

On the Forecast tab, you can manually specify the size of the planned scope. In such a way, you can override the default behaviour to calculate the total estimate of all Jira issues for a given scope:

This configuration option allows to quickly model different delivery scenarios. For example, if the planned scope size is equal to 200 story points, optimistic, realistic, and pessimistic delivery times are 11, 13, and 16 sprints respectively:

What-if scenario for the case when a planned scope is growing

The usual thing in our agile world is the case when new work is added to the already planned scope. Knowing the average rate with which new work is added, you can model the delivery timeline on the burnup chart. Here is the configuration:

From the configuration screen above, the scope is growing by 8 story points each sprint. So let’s check the burnup chart for such a case:

We see a big difference in forecasted delivery dates - forecasted velocity in each scenario tries to outrun the amount of work constantly added.

Chart configuration

For the details, please, continue to article.