There is no definite consensus on the need for risk management within the Agile method. This has led many to believe that risk management is irrelevant in an iterative model. Some follow the approach of ignoring risks until they manifest into issues; they then manage them through the natural sprint progression. I feel it's better to manage risks proactively in Agile.
Fundamentally speaking, risk is something that may occur and cause unexpected or unanticipated outcomes. Bear in mind that the outcome may have a positive or a negative effect. A positive effect is an opportunity, while a negative effect is a threat. This is distinct from an issue, which is an unexpected or unanticipated outcome. As there is a probability aspect attached to risk, its exact occurrence is unknown but does fall within the limits of the project. Because of this, managing risks may not seem to fit naturally into the Agile context.
Traditional project management techniques would recommend a risk register to monitor for managing and controlling risks. I prefer to keep a simple risk register with concise information. Too many fields in a risk register complicate the process and its administration. A simple risk register should consist of the following attributes:
- Description of risk: A one- or two-line overview of the risk. It should be simple and easy to comprehend.
- Date identified: Date when the risk was identified.
- Likelihood: Estimated probability of occurrence of the risk.
- Severity: The severity of the risk is assessed based on impact of the undesired outcome.
- Priority (optional): This could be either given an independent value or set as a product of likelihood and severity (above). A high-severity risk with a high likelihood should receive more importance than a high-severity risk with a low likelihood.
- Owner: The person who manages, controls, and takes action in response to the risk.
- Action: The response defined to manage/control the risk.
- Status: Indicates whether the risk is open or closed or being monitored.
It is imperative that the risk register be made available for the team so that it can be managed and monitored collaboratively. At every sprint meeting, the risk register must be reviewed and updated with any new information obtained over the sprint. This way risk management becomes an integral part of Agile.
Another interesting technique, introduced by John Brothers (Agile Times, 2004), relies on using a Risk Burn-down Chart. As elaborated by Mike Cohn in his article, the risks are collated into a table similar to a risk register. It consists of the following elements:
- Risk: Description of the risk in a few lines.
- Probability: Likelihood of the risk.
- Size of loss: Amount of time lost should the risk occur. This could be represented in days or story points.
- Exposure: This is computed as a product of the probability and size of loss (above).
An example is shown below. The consolidated risk exposure is shown in the final row of the risk register.
This risk register is reevaluated at every sprint meeting; its values are adjusted based on the current assessment of the existing and new risks. This would define a new value for the consolidated risk exposure. The Risk Burn-down Chart can be created by plotting the consolidated risk exposure across the number of sprints run by the team. An example is shown below:
In essence, the burn-down chart represents the status of the risk across the iterations. From a project management perspective, this is an excellent indicator of how the risks are managed and controlled. Similar to other burn-down charts, the ideal burn-down would be a linear decrease of consolidated risk exposure over the sprints.
These are some of the bare-minimum approaches that are effective in Agile. They're simple to manage and align with the iterative process. Adopting one of these is critical to having a proactive risk management approach.