A Risk is an uncertain event that could impact your chosen path should it be realised. Risks are events that are not currently affecting you – they haven’t happened yet.  Once a risk is realised, it has the potential to become an Issue.

Risks may be attributed to Political, Environmental, Societal, Technological, Legal or Economic (”PESTLE“) factors.

Mike Cottmeyer has described an alternative way to categorise risk:

• Business risk – e.g. value, priority, satisfaction
• Technical risk – e.g. code complexities/technical uncertainties
• Logistical risk – e.g. scheduling, resourcing

We use two measures to grade a risk:

1. The probability/likelihood of it being realised
2. The impact it will have if it is realised

As described in my post Agile Risk Management – The difference between Risks and Issues, a simple way of classifying a risk is through the use of a grading scale e.g. 1-5 or a Fibonacci sequence, with 1 being low impact/likelihood and 5+ being high impact/likelihood.

For example:

• A User Story is severely underestimated in the first sprAint, compromising the team’s ability to deliver their commitments (1,5)
• A User Story is severely underestimated in sprint 10, compromising the team’s ability to deliver their commitments (5,1)

In the first example, the Impact is low and the Likelihood is high.  Most teams take a few sprints to find their pace. Business expectations are managed to this effect and there’s a strong chance that the schedule has been designed to assume a high degree of uncertainty during this time.

In the second example, the Impact is high and the Likelihood is low. We would not expect an established team to severely underestimate a User Story. As such, the impact is likely to be much higher.

The results of this exercise are added to a whiteboard. Different teams tend to represent Risks differently (some as post it tags on stories, others using a risk matrix) – there’s no wrong way to do it so long as the risks are visible and regularly referred to by the team.

This board should be reviewed regularly as part of the Daily Scrum and/or as part of the end-of-sprint Retrospective.

The next step in this process is Risk Response.

Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!

Related Articles:

• Agile Risk Management for Projects and Programmes – OVERVIEW (agile101)
• Agile Risk Management – Risk Identification (Step 1 of 4) (agile101)
• Agile Risk Management – Assessing Risks (Step 2 of 4) (agile101) << You are here
• Agile Risk Management – Risk Response (Step 3 of 4) (agile101)
• Agile Risk Management – Risk Review (Step 4 of 4) (agile101)