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.
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.
