Risk Burn Down Chart

In my December blog, I covered the “Art of Risk Analysis” which skimmed over the idea of a risk burn down chart.  One of my main points is that risk review is a continuous process that should be checked on a frequent basis.  For larger projects where there are several risks, having a risk burn down chart is an excellent way to visualize the progress of closing risks but also track the level of total risk the project is experiencing from the team’s perspective.

Risk burn down charts are measured on the team’s interpretation of the expected duration a risk should last.  This duration should be updated along with the risk burn down chart during each review.  Here are my suggestions for a risk review meeting:

  • Who Leads: ScrumMaster / Project Owner
  • Who Attends: The delivery team along with the ScrumMaster.  The Product Owner is optional, but strongly encouraged to come at least to one review and obtain the results
  • When: At the start of each sprint (within a few business days).  Lasts 30 minutes unless it is the first time, then may go for an hour.
  • Goal: Update the risk register with the latest risks.  Risks should be either closed, updated or added accordingly to their current status
  • Process:
    • Setup: The ScrumMaster brings up the Risk Register (potentially blank if first time) along with the Risk Burn Down chart
    • Risk updates: ScrumMaster asks the team on updates for each existing risk.  Team is encouraged to speak up individually to obtain a consensus on each risk status
    • Risk identification: The ScrumMaster asks the team for any new risks introduced since the last update
    • Risk Review: Update the burn down chart and talk through the overall project risk level

The Risk Burn down chart should be included in status reports to management and be a topic for discussion with project sponsors and stakeholders to keep risk down to a minimum.  Keep consistency with your burn down chart with the number of risks tracked.  If you choose to have 5 risks tracked at the start of the project, keep it at 5 so trends can be equally compared.  If you believe your project risk level will be greater than your initial list, set your number to be above that list and count the missing risks as zero.  For instance, if you initially identify 7 risks but think it will increase to more than 10 in the future, make the list length 10 and count risks 8-10 as zero.

Here is an example of a Risk Register (poached from my December blog) and related Risk Burn Down chart made in MS Excel.  This is easy to create and manage although would be splendid if this was included in project management software packages like Jira, VersionOne, TFS, Rally and Pivotal Tracker to name several.

Risk Analysis

Risk Burn Down chart

You’ll see that for this project, the total sums of Expected Duration is going down, but note the burn down went up with the last sprint.  This is not unusual as new risks are discovered during the sprints.  This becomes a great communication message to leadership on whether project risk is being effectively managed.



Published by Agile Mike

“Agile Mike” has over 25 years of experience with software development and product leadership. He is published under the “Built for Success” column in CIO.com magazine and held the position of Vice President in the Agile Leadership Network. Michael has taught multiple SAFe courses for over the past three years to over 400 people and is currently an Enterprise Agile Coach at Lean Agile Enterprises and a certified SAFe SPC5, AWS Cloud Architect, Scrum CSP, and PMP.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: