While our delivery teams focus on designing, building, and testing product increments, we can pretty much guarantee that unforeseen problems will block their work. Once these have occurred, we call these impediments, because they impede work, but while they are 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.
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 it until it has passed. The aim of risk management is to stop a risk from becoming an impediment or to minimize its impact should that occur.
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. 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.
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.
Once we have assessed the impact and likelihood we decide what actions we plan to take and who owns it. The responses will 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.
For any risk or impediment that is high impact and highly likely or 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.
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 or it has been resolved, is no longer relevant, or it is simply no longer a problem.
If we have them posted on our team 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.