Risk Management in Agile

3 May 2013

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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.9 (9 ratings)

Comments

Cherie Silas, CSP,CSM, 6/9/2013 9:11:59 PM
I really enjoyed this article. I teach my teams that risk management doesn't go away and we do the same analysis regarding probability and impact but I have never thought to do a burn down chart as the probability the risk actually manifesting as an issue lessens throughout the project.

Great idea!
Andreea TOMOIAGA, CSM, 6/21/2013 3:55:49 AM
I liked this article and would add that opportunities should be also taken into account with a positive impact instead of negative (as in the case of threats). Then two risk charts can be maintained (the one for threats as illustrated in the example) and another one for opportunities. A chart comprising both would summarize the overall evolution of risk in its two dimensions (threats and opportunities).
Vishal Somal, CSM, 7/2/2013 8:44:30 AM
The best part of this is the Exposure bit, I really liked it! Otherwise the Risk Register composition remains the same but the biggest difference in traditional project life-cycle .vs. Agile (in this case SCRUM) is that the team owns the Risk Management which usually would have been the job of Only the Project Manager/Team Lead.
The team owning the risks is a great idea however these teams may not always have the need to know the Programme or Project Level Risks (if multiple Scrum teams are involved) which should continued to be managed by the Project/Programme Managers.
Ramon Anger, CSM,CSPO, 6/26/2014 9:50:55 AM
I just wondered: Who is from your point of view responsible for this risk list?

You must Login or Signup to comment.