What are Risk Management Metrics and what is the Risk Burndown Chart? Traditional projects have extensive processes designed to mitigate risk. Risk registers, probability calculations and other tools are used by project managers to provide a visual set of metrics used in reporting. Risk is either accepted or mitigated. Risks can quickly blossom into issues if they are not proactively addressed.
A common misperception in the use of Agile scrum is that risks do not require tracking and mitigation planning based on use of the continuous inspect and adapt model. The assumptions arise from the fact that risks are generally identified much faster than with traditional projects and can be quickly addressed. Short iterations and heavy emphasis on the use of collaborative techniques including automated testing does in fact provide a mechanism by which to identify and correct risks quickly.
Risk Management Metrics – Formal Risk Management
Small Agile projects will generally be successful without formalized risk management. Implicit techniques used with inspect and adapt address small items that can be easily managed. Larger Agile projects however, will require some form of risk management. In 2004, John Brothers addressed this through the creation of a risk burndown chart.
A risk burndown chart does utilize some traditional risk management metrics called for in the larger PMBOK body of knowledge. A list of known and anticipated risks will need to be documented and is known as a risk census. A percentage of probability is estimated. Probability is the likelihood that this risk will occur. Probability metrics can be categorized to provide consistency among a team (e.g.,):
- Low probability items 1-40%
- Medium probability items 50-70%
- High probability items 70-100%.
Risk Management Metrics – The Metrics
Teams can also use percentage metrics that are more subjective in nature. Whatever the approach chosen it is important to get agreement among key scrum team members and stakeholders on the probability metrics.
The next step in the assessment differs from traditional risk metrics because each risk is assigned an anticipated number of days that the risk would negatively affect delivery of a feature. If a feature does not have well-defined user stories and it has been accepted into the next sprint then there could be a risk of delay in the number of days that it will take to deliver the feature. Once each risk has a size of loss metric estimated by the number of days, that number is multiplied with the probability to determine the risk exposure in days. The risk census should be created during the first feature backlog discussion and updated frequently throughout more complex efforts as new risks are identified, accepted or mitigated.
Risk Management Metrics – The Risk Register
The risk census is a much simpler tool to use than a traditional risk register. Risk registers generally contain several data points such as a description of the risk, who is responsible for the risk and due dates to name a few. Agile’s transparent and collaborative processes hold all scrum team members as responsible for accepting and finding solutions.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
The Risk Burndown Chart
Agile scrum risk management can utilize a risk burndown chart to create a visual that mirrors the feature burndown process. Agile scrum uses visual representations of feature delivery that are most useful during daily sprint ceremonies. This same visual representation of risks over time can be used to help teams quickly identify situations where they may not have adequately planned smart feature deliverables. One assumption is that as scrum teams gain greater efficiencies through increased velocity and stakeholder feedback that risk will decrease in a linear fashion. This would be in line with the volume of features delivered through sprints. It is important to recognize that complex projects will inevitably identify additional risks throughout the life of a project.
The creation of a risk burndown chart is not simply for visualization of risks. A scrum team may recognize that the number and complexity of risks versus the number of features needing to be delivered are creating a significant delay of time or quality. The visual representation should be a call-out to the scrum team ( Scrum Master, Scrum Product Owner and Scrum Development Team) that a timeout should be initiated to address the risks.
Here, the Agile Scrum Master will hold a special 30-minute Sprint Review ceremony to do a deep dive into the open features and discuss with the larger team why they believe that the risks are compounding versus being reduced. It could be a lack of the right tools (hardware, storage, software), not having access to the right people or overestimating velocity.
Risk management is not always given the same focus in projects using the Agile scrum framework as it is in traditional waterfall projects. Smaller Agile projects can effectively manage risks through the short iterative cycles that are part of 2-4 week sprints. Larger, more complex Agile projects require some type of formal risk management. Risks that are not addressed could lead to a reduction in the Return on Investment outlined during the Sprint Planning meeting due to lost velocity, delays in delivery of critical sprint features and increased costs. The scrum master is responsible for managing risk census and burndown charts. All team members have a responsibility to pause a project if the complexity and number of risks increases significantly without explanation during the life of a project.
The ‘Agile Scrum Master Training Course With 59 Seconds Training‘ is now available for free. This free Scrum Master Certified Online Training Course provides an in-depth understanding of the Agile Scrum Master roles and responsibilities, where you find out what a Scrum Master does and how to do it. During this free course you will learn all of the tools needed to succeed as an Agile Scrum Master.
Thank you for choosing us to learn about the Agile Scrum Framework.