Agile Risk Management – Assessing Risks (2 of 4)

risk-management-assessRisk Assessment is the second stage in the Agile Risk Management process. This stage is preceeded by Risk Identification, and followed by Risk Response and Risk Review.

A Risk is an uncertain event that will 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 becomes 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:

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)
Risk Matrix - Impact vs. Likelihood
Risk Matrix - Impact vs. Likelihood

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.

This Impact vs. Likelihood assessment is done quickly – it’s not an exact science, we just want to get a sense of scale, urgency and priority so we can determine the most appropriate Risk Response.

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 Agile101 RSS to be notified when I upload new Articles Templates and Tips!

Related Articles:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s