Agile Risk Planning...

I'm going to oversimplify a lot of things in this post. I'm doing it for two reasons... it's not the most interesting topic, and I'm really just trying to throw out a very basic solution to what can be a very complex process. Many environments don't even do risk management, so my theory is that something light covering 60% of your needs is better than nothing at all.

What do we know about Risk Management?

Well, we are supposed to do our best to anticipate what might happen and mitigate it. The best way to do this is:

1. make a list of all the bad things that make you lose sleep (or just worry you)
   
2. assign a probability of each happening
3. assign a cost of impact if they occur
   
4. multiply all of the probabilities by all of the costs and get a total cost
5. put that money in the bank (or time padding on the project plan) to protect against it
6. constantly manage the list to your best knowledge
7. make decisions about how to spend resources to mitigate or remove risks (if you can do this for a fraction of the cost of it actually happening)

Your approach to this could be very scientific, thorough, and accurate... or you could just make some quick gut calls.

What is the agile solution I propose?

First, I believe that the amount of time needed to be invested in this process to make it very accurate is an amount of time and resources that most teams don't have. This is the same issue as estimation for stories and tasks in agile. There's a reason we do poker planning, and it think it might apply here.

1. Let's start with the basics... have the team spend a few minutes each release (every few sprints) brainstorming risks with the guidance of a PM and the PO. The PM, PO, and Scrum Master should have already pre-seeded the list to speed things up since this isn't the main focus for the team.
2. Now assume the risk will occur. Have the team estimate the impact of the risk using the same scale you estimate stories by.
3. Using poker planning, assign a probability of each happening (but use a scale of 1%, 10%, 25%, 50%, 75%).
   
4. Multiply each of the probabilities by its corresponding cost and sum for a total cost. This is your risk budget.
5. Here's where I assume you have an electronic version of your backlog (be it excel, or a tool like VersionOne). Add a story to the bottom of your backlog called Risks. Under it, create a task for each risk. Put your total risk budget as the story estimate.
6. Go.
   

Your system should include this story in any projections it makes for the burndown chart... so now you have that buffer built in to your projected product backlog. You have hedged your bets against the risk odds, and your are reasonably protected without being overly protective.

Responsibilities moving forward:

• Management is responsible for keeping this list up to date. Add/Remove risks as appropriate.
• Any work that can be done to reduce or remove items in this list at a fraction of the cost of the risk occurring should be pursued.
  
• The team should re-estimate both probability and impact cost periodically based on their updated knowledge (this supports the cone of uncertainty philosophy)

That's it... that's my poor man's soluton. Time to apply it and see if it is "just enough".

Final Note- Since I'm not as experienced in hand's on Risk Management as I could be, I welcome any ideas or feedback on this post... especially errors in my thinking. Feel free to beat me up. Most of the places I've worked, I haven't had time to focus on risk because the biggest issue is teaching people how to make and follow a plan along with communicating well as a team (hence my interest in agile).

Update (11/25): Here are two very good articles by James Shore about risk management and estimate inflation if you want to see a more in-depth look at these topics.