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:
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.
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.
Tags: risk, sprint planning
Mike,
The risk burndown is only going to be as accurate as the numbers behind it. Getting it right requires the calculation of the impact of individual actions that may occur from sprint to sprint. The numbers are difficult to calculate with at this fine level or detail.
Is there a good way to calculate that a risk probability was 20% and after doing one action, it has reduced to 18%?
Unless there is, the risk burndown becomes meaningless as one can make it say anything.
Hi Siddharta–
I’m sorry you find the technique meaningless. Since that’s so, I recommend you don’t use it.
And of course it would be practically impossible to say “we’ve reduced risk from 20% to 18%.” But that does not mean it is impossible to say “we’ve reduced risk from about 50% to about 20%.”
The purpose of measuring is not to be exact. The purpose of measuring is to reduce uncertainty. I asked a waitress recently “How big are the cups and bowls of soup?” She didn’t give me an exact answer in number of ounces. She held her hands apart showing me the approximate size of my two options. That was enough for me to decide. (I went with the larger!) Assessing risk in this way is a time-tested project management technique that can also be used on agile projects. Yes, it can be abused by teams implying false levels of precision. In my mind, though, that does not invalidate the technique.
Hi Mike,
I think this is a very good idea.
I treat Scrum as a framework. I try to stick with vanilla Scrum rules but sometimes add some project management tips and tricks.
My projects tend to have high visibility, be complex, and be for complex organizations, so risk management is important for me.
On agile projects, I use some of the good stuff from PMBOK and Prince 2, like risk management. I tend to use a similar risk matrix based on probability and impact. You assess impact in days, which for a labour intensive project like application delivery is sensible in my view.
On tradition projects, I use the daily meeting, to the dismay of many of my colleagues at the start, but after the first meeting everyone sees the value in hovering up issues & risks every day.
My point, there are good aspects to both worlds of project management, and common sense should apply when to use certain aspects, without creating a burden on your project.
I will adapt my approach based on your article. Thank you.
Dear Mike,
According to me, the most important thing to consider when it comes to risk management is the way risks are treated (i.e. avoided, mitigated, shared, or transferred). Another important aspect to be taken into account is linked to type of risk. In case of opportunities risks, that in some cases, are supposed to be upsided as much as possible, is will create inconsistency in the burndown chart.
Overall, I like the idea of using this ‘tool’ for a better view of how risks are evolving during the SLDC. Maybe if this chart will be a mandatory deliverable for an iteration/sprint, the risk management will be more seriously considered by the team.
Thanks.
Hi John–
I like your pragmatic approach. Like you, I mix all sorts of ideas into how I manage projects. I don’t care where an idea originated as long as I think it increases my chances of success I’ll use it.
Hi Loan–
You are absolutely right that the most important thing is how risks are treated. Well, maybe that’s second. Maybe first is that we actually stop for a moment and think about what risks exist (i.e., create the risk census) but a risk census without some consideration of how we’ll treat each risk isn’t very valuable.
I’d been meaning to write this blog post for six months and kept not having time because I wanted to talk about strategies for handling risk. I eventually decided I didn’t need to cover all that because it’s so well covered in the traditional literature. So my hope with this post is that a few projects start thinking about risk in a more deliberate manner (not all projects need to) and that they now have an easy way to visualize changes in that risk.
Mike, great post. These techniques are great conversation starters that would otherwise not happen on projects. As for Siddharta’s concern about not being able to calculate the probabilities, McConnell’s Rapid Development book has a simple technique which I will try to not butcher here:
Take real amounts of money and ask yourself, would you take this bet? If Risk X happens, you lose $100 (downside), but if it does not happen, you win $300. Keep changing the amounts until you are comfortable being on either side of the bet. Then divide the downside by the total amount of money at play. In this example it’s 100 / 400 = 25%. That’s the probability of the risk occurring.
Hi Luis–
Thanks; I’m glad you like the post.
That’s a great technique. I read and liked Rapid Development quite a bit but didn’t remember that technique. I’ll have to use that in the future so thanks for sharing it.
I do, though, think Siddharta’s point of “don’t get too precise” is valid. I’m thinking back over all the risk lists I’ve seen and meetings I’ve been in to discuss them. The only time I ever saw a risk census (like the one in the post) that had a percentage that wasn’t a multiple of 5 was when someone wanted a 1% risk listed, more for tracking it and identifying it than for really thinking it was 1% likely and not 2%. Generally I’d say risks are listed at 1%, 5%, 10%, 20%, 25%, and 50%. Above 50% and we’re working to resolve it. The other numbers can perhaps be distinguished from one another. (Maybe 20% and 25% can’t but those numbers are more a matter of preference among various teams.)
Thanks again for the new technique.
Hey Mike!
I’m on a team that actually put this to practice (and is currently on that project). It worked very well for us (we were on a very risky project; we reduced nearly ALL risk by the 6th or 7th iteration). It’s a very satisfying experience and the best part is that each time you reduce risk you increase developer confidence that the system is going to work!
What we found interesting is that our focus on risk/value was inversely proportional. We’ve also switched from a 2 week iteration based approach to a user story driven approach (where we focus on adding value and not much else). It’s an interesting case study.
I could talk for ages about our experience and would love to talk about this more if you’re interested. My email is derek r hammer at gmail dot com. It’s exciting to see that we weren’t crazy crack addicts when we implemented this and put it to use!
Hi Mike,
It seems easier to simply maintain a list of risks and a status of “open”, “mitigated” or “contingency in place”. The numbers at a high level are useful to see the exposure, but once it is mitigated or a contingency is in place, then its struck off the list. Much like how a story is done or not done, not 50% done or 80% done.
Do you see an advantage in visualizing it as a burndown?
Hi Derek–
That’s great to hear you’ve been successful doing this. A great place to share your experience would be through the Scrum Alliance weekly articles. Email me if interested and I can put you in touch with their site editor. She’s always looking for good articles and my personal favorites are the ones that are experience reports. It sounds like yours would make a good one.
Hi Siddharta–
Yes, it’s definitely easier to maintain a list without columns for probability and expected impact. However, I’ve never worked on a project of any consequence where we created that list and then weren’t asked the follow questions of “How likely is this to happen?” and “What’s the impact if it does?” Note that I’m not saying everything agile project needs this (in fact, perhaps less than half need any explicit risk management at all). And yes in some cases I see an advantage in visualizing the change in risk over time.
Mr. Cohn
What we are trying to do here is to bring down the cumulative exposure down.
But then, I am not really bothered about the Risk 5 whose probability and impact are 40% and 5 days respectively as much as the second risk whose respective parameters’ values are 35% and 20 days respectively. Without being able to track the risk which has the most impact, do you not think that I am at a disadvantage.
And how do we really know about the status of the risk in a particular timespan. Because, we don’t bother about all the risks (prioritized top 10 as you say) all the time. In fact, we may choose to skip a particular risk to the next iteration because it doesn’t have any impact.
Thanks,
Vikram.
Hi Vikram–
First, I am not saying this is all a team needs to do to effectively manage risk. I am presenting an interesting visualization of risk over time. I do not suggest throwing out all good things we’ve learned about risk management over the last 30-40 years.
I don’t know why you say you would be unable to track the risk which has the most impact. I never said not to do that. My goal when I introduce this to some (not all) agile teams is for them to do a little risk management rather than none. For its most important risks I have team’s track each risk on its sheet of paper that notes changes in the risk, assumptions, mitigation and recovery strategies, and so on. There is more to risk management than I’ve covered here–this blog post is about visualizing risk, not everything about risk. Take the good things you know about risk management, keep doing them, but consider visualizing them this way.
And of course you can track more than 10 if you are willing to invest the time in doing so. Often though those risks are so small as to be inconsenquential.
I think the purpose of risk assessment is not to create a number, but to prevent the risks from occurring.
I like to start a project with a retrospective. It is useful to ask the question, ‘what has gone wrong before?’ It may even be useful to ask the question, ‘what did this cost us?.’
In one case, the customer identified items like: we received untested software. the software was design or implementation mistakes which made it unsuitable for the purpose. Et cetera. Mitigating these risks was a major reason for moving to agile.
Oddly enough, the customer chose to the project waterfall anyway (and the impacts were predictable). The customer’s culture was not agile. So it would seem recognizing the risk may not be enough to prevent it if the cure is sufficiently alien.
Cheers,
Peter
Hi Mike,
great post. This works just fine as a starting point for those PMI enthusiasts who think Agile/Scrum has no risk management. From what you propose one can easily adapt to her reality and deepen the technique. As for precision I would say goes on the same direction as software estimation. The probability of a risk to happen is an estimate, so why stick to complexity if you can’t be precise?
As an extension I would add a systematic way to obtain the risk percentage and impact. Percentage based on a token placed at each story which could contribute to that risk plus its story points: (token weight + story point)/100 – a transform function needs to be derived to certify we cover all possible values. For the impact, we could somehow use the business value of each story.
I think systematizing techniques like this makes manager happier and does not impact agile development.
Thanks, Heitor.
I’d have to see this in action to fully grasp it.
Personally, though, I’m not a big fan of putting a “business value” on each story. In general, most user stories are too small to have discretely distinguishable value—much of the value of the story comes from having it in combination with other stories. For example, there are some stories that if removed from a product will remove ALL of the value of the product. It would be impossible to put a value on those.
Mike,
You’re on to something. We have several charts like this. Schedule margin is one. It burns down as the program proceeds and a similar manner with a target and an actual margin curve, and a projected impact on the completion date. Same for cost margin (Management Reserve).
There are subtleties of course. The first is the probabilistic nature of the risk “days” itself. This is the variance in the estimate in the impact. For simple system, this can be a Triangle distribution with a Most Likely and an upper and lower bound. These are always asymmetric of course.
The larger challenge is the correlation between the risk – coupling in the same manner as interface design. But for the 1st round you’ve got it right.
Hi Glen–
Thanks for your comments. If you approve, I know I must be OK on this since I know the rigor you apply to things. Thanks.
should be pretty nice tool together with alternative burndown chart to project the release date with given scope, average velocity, average scope change and this stuff.
I didn’t track risks so ‘formally’ at my projects. We just said there are red and yellow ones with impact on release goals and sprint goals. thanks!