Agile Zone is brought to you in partnership with:

Mike Cohn is a consultant and trainer who specializes in helping companies adopt and improve their use of agile processes and techniques in order to build extremely high performance development organizations. He is the author of Succeeding with Agile, Agile Estimating and Planning, and User Stories Applied for Agile Software Development. He can be reached through his website at Mike is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

Managing Risk on Agile Projects with the Risk Burndown Chart

  • submit to reddit

Risk management is a central part of traditional project management and is included as one of the knowledge areas in the Project Management Institute’s (PMI) body of knowledge. In many of my classes, participants ask how Scrum and agile address risk management. Some are concerned that agile or Scrum ignore risk management completely. Let’s see why this is the case.

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. To put it in risk management terms, for these projects the likely savings from explicitly managing risks is outweighed by the cost of explicitly managing risk.

So while some short and inherently low-risk projects can be safely undertaken without any formal risk management, other projects are likely to benefit from explicitly managing risk. To see how we can do this, I want to describe a technique originally introduced by John Brothers in The Agile Times in 2004: the risk burndown chart.

Before we create a risk burndown chart we first need something akin to the typical risk census, which is merely a list of a project’s top risks along with the probability of the risk occurring and the size of the loss that would occur if it did. An example is shown in the following table, which I’ve simplified by eliminating a few columns that are not essential to this post:

A risk census

Our simple risk census here describes each risk, provides an estimate of how likely the risk is to occur, the impact to the schedule if the risk did occur, and then the expected exposure to the risk which is the probability multiplied by the size of the loss. I recommend creating a risk census during the first sprint planning meeting and then updating it quickly during subsequent planning meetings as new risks are identified or as the probabilities or sizes of known risks change.

The risk burndown chart is then created by plotting the sum of the risk exposure values from the census. My recommendation is to sum only the top ten risks even if the team has identified more. Do this even if the top ten change over the course of the project. A sample risk burndown chart will look like this:

As with a regular release burndown chart, we should see a linear drop in risk over the course of the project, as shown in the red line of this next risk burndown chart.

a risk burndown chart.

When risk is not coming down at the appropriate rate, the team may want to budget some time in the next sprint to work directly on risk mitigation.

So as we can see from these examples, it is possible to take risk management seriously on agile projects that need to explicitly do so. And the risk burndown chart provides a convenient way of visualizing changes in risk.

Published at DZone with permission of Mike Cohn, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)