Release Burn-Up Chart

Few lines about Release Burn-up Chart

“Release Burn-up chart” in scrum adds a great advantage. It allows the user to pinpoint issues like a deviation from the planned project path. The chart states the team’s progress towards achieving the release goal by tracking how much work the team has already covered, that is, how much work they have burnt up.
The features includes:

• The vertical axis shows the amount of accepted work (in hours)
• The horizontal axis represents the dates contained within the release.
• The blue bars represent the completed story points
• Total scope of works in the release is represented by a black line

The release burnup chart lets you see:

• How much work has been completed
• How much work has been added or removed
• How much work is remaining

Why is Release Burn-up chart required?

A release burn-up chart is basically required to track team progress as well as to develop data-based forecasts that can be used to help in achieving a release plan.

Who all should be involved in structuring the Release Burn-up chart?

The following individuals will be involved in the Release Burn-up chart

• Scrum Team
• Stakeholders

How to create a Release Burn-up Chart

A release burn-up chart helps the scrum team in tracking the team progress and developing data-based forecasts that can be used to help balance trade-offs in achieving a release plan. In case of iteration, the charting data has to be updated.

Release burn-up charts are built using summed measures of work overtime. This could be called story points per sprint in scrum. However it can also be used with other frameworks like Kanban, for example as work items per week.

To come up with these charts, there are many tools that will generate, but through spreadsheets you can have a better control over the content and delivery. To make the concept clear, we shall use Microsoft excel to develop the release burn-up chart. We shall assume that the development team has just completed sprint 6 and would like to forecast out another 9 sprints. The value will be measured in story points.

Before moving further, lets us keep in mind

• It’s better to forecast, but not commit
• Prepare to inspect and adapt
• Good data will take time to develop so just get started
  

Step 1:

• You can take a look into the Velocity Data, which the team has already tracked. Before that, let us understand what Velocity of a Sprint means.

Velocity of a Sprint:

Velocity of a Sprint is how much work a project team can get done per sprint. It is typically used to estimate how many features can be accomplished each sprint.

Step 2:

• The second step involves creating a spreadsheet using the velocity and adding a column for the story point summation.
• Plot iterations on the horizontal axis and the summed story points on the vertical axis. And now, extend the iteration count into the future, let’s forecast through sprint 15.

Have a look into the picture, one by one

Step 3:

• In a separate cell, calculate the story point average for the last 3 sprints in this case
  
            15+30+21=66/3=22
  
  
• Add a column to contain the forecast average and carry over the current sum for ‘today’ as a starting value. Forecast into the future summing the average overtime.
• Here let’s not commit, thinking it would be easy that the team will achieve 228 story points at the end of sprint 11.
• This is only a possible outcome, if nothing changes and the last 3 sprints will be the accurate indicator of future performance.
  

Step 4:

• Now we will have a separate cell and let’s calculate the Standard Deviation for the last 3 sprints. We will use this value to establish a reasonable upper and lower bounds for the forecast. Here,
                                               
                                                                σ = 7.55
         
• Create columns for forecast highs and lows where the value is equal to the forecast value + or - the standard deviation. The deviation is cumulative as the forecast extends into the future. Plotting the high and low values in addition to the  average forecast should demonstrate a cone of probability.
• An alternative and also a relatively simple, non statistical approach, is to use the average of the 3 highest sprints and 3 lowest sprints to establish the variance. Around the average. As we are more focused on accuracy and not precision, this approach will be sufficient.
• We will assume the data is normal (fits a bell-curve) and will not change over time.These assumptions may not be very strong. However, this approach should provide a good approximation. Given these assumptions and using a standard deviation on each side of the average will result in a 68% confidence level.
  

Step 5:

• With a proper forecast, it is way simpler to evaluate what scope might be completed within a given time. In the example here, the team should be able to complete between 219 and 325 story points by the end of sprint 13.
  

Step 6:

• It is equally important to know when a given amount of work will be done. This can take the form of an MVP over time. Note this value may change as the business responds to mark the need and capability of the team.
• In this example, the, the MVP at 225 story points is likely to be achieved between sprints 10 and 14.
  

Step 7:

• For a team, it is important to update the data on a regular basis, iteration boundaries being the most common time. In our example, sprint 6 has moved to historical and ‘today’ is identified as sprint 7. Values have been updated, including the average standard deviation for the last 3 sprints i.e 4,5,6.
• You must have noticed that the width of the cone has reduced. A greater predictability in the time is reflected in the smaller standard deviation, being reduced from 7.55 to 4.51. This may arise from the team hitting its stride, increasing predictability, and improving forecast variability.
• Notice that the average velocity has also increased, from 22 to 25, and is seen as a slight ‘tip up’ of the cone. This, coupled with an increased predictability indicates achievement of the MVP as likely between the sprints 10 and 11.
   

What is the outcome of preparing a Release Burn-up chart?

Release Burn-up chart is used to track a progress of a release by comparing planned vs completed work. One gets to know how much work the team has completed over a certain span of time. The work could be either user story points or the number of hours spent. This completely depends on your project settings.