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.

It is important to point out that not all risks become issues. Some risks materialise and are absorbed into a sprint/project/programme with negligable or no impact at all.

The aim of risk management is to either…

1) prevent the realisation of a risk or;
2) to minimise/manage/neutralise the impact of this risk once it has been realised.

If you succeed in point 2 then the net impact of realising the risk may be totally acceptable i.e. no issue at all.

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

We use two measures to describe a risk:

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

The field of Probability is a really complex science (Actuarial Scientists make a career of it!) – I once spent a month attempting to calculate the likelihood of a High School student achieving an A-grade. Despite considering over 100 input factors, there was always something else that could affect the outcome e.g. video game preference, choice of pet and favourite TV show. I could have gone on for years.

In faced-paced, dynamic environments like Software Development or Digital Publishing, we don’t generally have the luxury of spending weeks trying to figure out whether something is going to happen or not.  We need to respond quickly and use our judgement to identify actions/activities that will help us to:

1. Accommodate the potential outcome and;
2. Make the potential outcome work to our advantage (if possible!).

Risks vary in impact severity – some have the ability to dramatically affect your preferred path, whilst others come and go without much notice.

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 sprint, 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.

For these types of classifications, you need to first agree on what would constitute a ’1′ or a ’5′ as you’re measuring the relative impact/likelihood of a set of risks.  I accept that this is a less precise way of assessing risk but it seems to do the trick nevertheless

It is also important to point out that risks are usually thought to be all bad.  Fact is, the net impact of realising a risk can be either positive or negative. With that said, positive risks are more regularly referred to as ‘opportunities’ and as such are handled differently.

Some examples of positive risks are:

• A User Story estimated as a ’21′ turns out to be far less effort than anticipated
• The design of the release plan enables the project to become self-funding within three sprint

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

Related Articles:

• Agile Issue Management for Projects and Programmes (agile101)
• Agile Risk Management for Projects and Programmes (agile101)