Four steps to agile risk management

While our delivery teams focus on designing, building, and testing product increments, we can pretty much guarantee that unforeseen events will interfere with their work. Once these have occurred, we call these impediments, because they block or impede work. While they are still just potential, we call them risks. It is good practice to identify risks and impediments as early as possible, then work to mitigate their impact or resolve them. We call this risk management.

Edit: Risks can be positive as well as negative. That is, there are unforeseen events that could benefit us (such as a new customer) as well as block us (such as losing a delivery partner). In more formal risk management approaches, we distinguish between these as opportunities and threats. On teams following agile practices, however, there is rarely enough time to worry about the difference; if it happens, will it have an impact for which we need to plan. 

As soon as a risk or impediment is identified, the team should actively manage it. First it needs to be documented and assessed, with some agreement on how to respond, and then monitored until it has passed. The aim of risk management is to stop a risk from becoming an impediment or to minimize any negative impact should that occur.

1) Identification

When we have identified a risk or impediment we should immediately write down a short description about where and when it was found. On agile teams we typically capture these on sticky-note and ensure they are visible to everyone, we stick them on our task board. When multiple teams are working on the same product, we often use a shared risk board that we will stand up around for the Scrum of Scrums.

Alternatively, many organisations now use a digital agile management tool, which allows teams to catalog the risk or impediment so that it can be seen by anyone with access to the tool.

2) Assessment

Once we have captured the risk or impediment, we need to assess its potential impact and likelihood, and the date by which it might become critical.

• Against impact, the ranges stretches from minimal to severe.
• For likelihood, the range is from unlikely through to already occurred.

For an individual risk or impediment, it can be enough to assess it on a scale of low – medium – high; however, when assessing a number of parallel risks and impediments, it helps to assess them on a numeric scale of 1 to 5, as we can then calculate a risk score and aggregate overall risk levels.  A risk score can be calculated by multiplying the impact and likelihood.

We consider a combined risk score in the range of 1-6 as low risk, while 7-14 would be medium risk, and 15 or above would be considered high risk.

Edit: Some organizations might use a range of 1-9 on each axis, meaning that the combined risk score is higher; if that is the case, then anything in the range 1-15 would be low, 16-44 medium, and 45 or above high. 

3) Response

Once we have assessed the impact and likelihood we decide what actions we plan to take and who owns it. The responses typically include options of resolving, mitigating, or accepting.

• In resolving it, our actions should fix or remove the underlying issues.
• In mitigating it, our actions should reduce the impact or likelihood.
• In accepting it, we would be agreeing that we can live with the impact if it occurs.

Edit: In more formal risk management approaches, we could also have response options of transfer, share, enhance, and exploit. In transferring or sharing it, we have wholly or partly made it someone else’s problem. In enhancing it, we are doing what we can to make it more likely. In exploiting it, we make the most of it when it does happen. The last two would only be used with opportunities / positive risks.

For any risk that is high impact and highly likely or an impediment that has already happened, we need to take immediate action. If we don’t have the capacity or capability to resolve it, we should look for someone else who can help. In many agile teams, this will mean the scrum master escalates it.

4) Monitoring

Having assessed and decided the actions we can take, we need to continue to monitor the ongoing status of any risks and impediments.

If the impact or likelihood changes, the risk score should be updated which could trigger a re-assessment. Perhaps we can close it off when the risk score becomes very low, it has been resolved, it is simply no longer a problem, it has expired, or for some other reason no longer relevant.

If we have them posted on our team board or shared risk board, we could check in on them briefly at the end of our daily scrum. As above, when multiple teams are working on the same product, we will review these in our scrum of scrums. We should also factor these into our sprint reviews and retrospectives.