In Prioritization Techniques, Part 1, I described a variant of a risk analysis and prioritization technique popularized by Michael Lant.  The process assesses probability and impact and uses the result to rate the priority of the risk.  Using a structured approach helps reduce the emotion generated when discussing risks.

A second approach adapted from the writings of Mike Cohn[1] leverages some of the same ideas noted above with a few twists.  As with the previous process, this process should begin during chartering (Sprint Zero or some structured pre-project activity) with the results being updated during each subsequent planning meeting.

The process is as follows:

  1. Develop a census that describes each risk. Add each risk to the product backlog as a user story.
  2. Rate each risk. Estimate of how likely the risk is to occur, then estimate the impact (i.e. how long it would take the team to recover) if the risk occurred.
  3. Calculate the expected exposure to the risk, which is the probability multiplied by the impact.

An example of the analysis is shown below:


Update the analysis at any time as new risks are identified or as the probabilities or sizes of known risks change. Probability and impact are not fixed and will change over the lifespan of the project. Mike Cohn recommends only focusing on the top 10 risks (a variant of the 80/20 rule). Teams I have been involved with have experimented with monitoring all risks and monitoring a subset. I tend to agree that a subset works best. Set the constraint based on the information needs of the team and organization. It will help you focus on what is truly important, and tends to reduce excessive navel gazing.

The venerable burn-down chart can be used to monitor and report risk across the life span of any project or program. An example of a risk-burn down is shown below:


The concept of the risk-burn down was introduced by Mike Cohn and John Brothers in The Agile Times in 2004. A graphic tool to monitor risk helps focus attention, and helps both the team and other stakeholders understand the potential impact of the primary risks. It also helps show how potential risk impacts abate over the life of the project, either through mitigation, sublimation or just magic.

A second measure of risk for Agile projects is Value at Risk. Value at Risk represents the potential impact of risk on the value of a project or portfolio of projects. Monitoring includes an evaluation of the potential cost impact of avoiding the risks that have not been fully remediated weighted against the probability of occurrence. Where the cost impact of risk is above program risk tolerance, specific remediation plans will be established to reduce the estimated risk impact. The Value at Risk metric provides the team with a tool for prioritizing risks and risk management activities. Value at Risk can be tracked using burn-down charts.

See the Metrics Minute entry: Value at Risk for a more in-depth discussion of the metric and how to use it. The concept of value shines a light on how much of a project’s value would potentially be erased if a risk became an issue.

Agile is inherently less risky, assuming you actually implement and practice Agile techniques. Note that I did not say that Agile projects are risk free. Assuming we keep an eye out for risks, if we monitor those that we find and transparently share what we learn inside and outside the project team, we stand a good chance of minimizing the potential of a risk becoming an issue. A black swan will occasionally happen in an Agile project, but because we are always on alert we will recognize it quickly and decide what to do about it as a team.