Primarily Risk is something that may occur and cause unexpected or unanticipated outcomes.
Traditional project management applies full-blown Risk Management techniques and recommend a full-blown risk register to monitor for managing and controlling risks.
However there is no definite consensus on the need for risk management within the Agile method.
In many of my classes, participants ask how Scrum and Agile address risk management. Some are concerned that Agile or Scrum completely ignore risk management.
Here is the rationale. First, a great deal of explicit risk management becomes unnecessary when a project uses an agile approach. The short iterations, single-minded focus on working software, heavy emphasis on automated tests, and frequent customer deliveries help teams avoid the biggest risk most projects face—that of eventually delivering nothing. So, it is not surprising that many agile projects forgo any form of explicit risk management
This has led many to believe that risk management is irrelevant in an iterative model, rather manage risk & issues through the natural sprint progression.
Because of this, managing risks may not seem to fit naturally into the Agile context.
However risk can be undertaken in Agile also without any formal risk management, may be preferably thru simple techniques:
- Simple Risk Register
- Simple Risk Burn-down chart
Below are the attributes to keep risk monitoring thru simple risk register.
Risk register must be made available for the team so that it can be managed and monitored collaboratively.
- 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.
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.
Risk Burn-down Chart
Another interesting technique, to managed and controlled risk is thru Risk Burn-down Chart (Originally introduced by John Brothers in The Agile Times in 2004)
In essence, the burn-down chart represents the status of the risk across the iterations.
Similar to other burn-down charts, the ideal burn-down would be a linear decrease of consolidated risk exposure over the sprints.
Risk Exposure is collected into a table similar to a risk register as below.
- 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).
This consolidated risk register is reevaluated at every sprint meeting; its values are adjusted based on the current assessment of the existing and new risks.
Summary:
Above are two 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.
Regards,
Arun Manglick
