Thanks for publishing this article. I see the uses of this chart, great. We can visualize the overall risk exposure and see risks are burning down as we progress. I like the suggestion that if those risks are not burning down take extra actions in one of those sprints, only if it helps. Mike, you should recommend this Risk burn down chart in to PMBOK Guide. I see absolute benefit of it.

After reading few of first comments I would like add my own madness:
- PMs or Scrum masters are not expected to take a decision on everything. He/she is just a facilitator of the team with great authority to drive. Autocratic PMs will never succeed.
- The same logic applies for Risk items also. Team collectively identifies Risks and their probabilities / impact. PMBOK Guide has wonderful definition, explanation for Impact matrix. Every team can define their own impact matrix appropriate to their project.
- Same way using various analysis, data gathering and expert judgment, team can identify the probability of identified risk items.
- Risk itself is a prediction and on top of it, Probability is super prediction work. The team should discuss and take some stab at it. If team collectively predicts it as 20% or 18%PM / SM needs to log it. Underline the word prediction!!
- And remember both probability and impact constantly change. So Risk management is not one time job. It is day to day job.
- Simple example: Consider risk associated with Cyclone. Based on changing weather conditions, impact can change up or down and probability also can change up and down. We just need to react accordingly.
- Somehow I can’t think of any reasons to have a scientific formula to identify those numbers. If someone finds a formula, then we can fire all PMs and SMs. Projects can be managed by Excel sheets and analysts. What I mean is, PMs should manage those risks when they occur. I didn’t read McConnell’s book. His method might be correct in his context. I don’t know the context.
- If team predicts that probability change from 20% to 10% then go with it or if they predicts it increased from 20% to 50% then start preparing to implement your RISK RESPONSES. As everyone knows, Mitigation is just one type of response.
- Another benefit is, any risks and probabilities changes greater than 50% or more then team get an opportunity to involve senior management and rest of the client team. So no one will be surprised.
- One another benefit of Risk management is to pull the plugs off. If any risk item is making your project worthless, you can just stop the project.
- IF Burn down chart shows zero or minimum exposure, then you can divert all of your contingency reserves to other work. That’s straight benefit.

I like this tool, Risk Burn Down Chart!!

I like tracking and visualizing risk on agile projects so was really pleased to see that you’d covered this. Using a burndown chart is a good idea.

I use a simpler categorisation for probability and impact, simply categorising each into low, medium or high. In the past I’ve come up with the different actions to address the risk, either by myself or with team members.

I’m now thinking that a better approach may be to work with the team to come up with the stories they feel are needed to handle each risk and get them to estimate how many story points those stories are. We could then add these stories to the backlog and plan risk-reduction stories into each iteration as part of normal iteration planning. No need for a separate burndown chart?

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!

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.

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.

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.

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