Risk Response is the third stage in the Agile Risk Management process. This stage is preceeded by Risk Identification and Risk Assessment and followed by 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.
As touched upon in the Identifying Risks section, Agile Project Management has Risk Management built into it’s core. The meetings that take place in the run up to Sprint Planning offer numbers opportunities to mitigate/avoid Business, Technical and Logistical risk realisation.
If and when we do need to accept a ‘risky’ story into a sprint OR if we’re concerned about an alternative risk of disruption, then we need to Respond in a way that will enable us to:
- Accommodate the potential outcome and;
- Make the potential outcome work to our advantage (if possible!).
Tim DeMarco and Tim Lister describe four different Risk Responses in their book “Waltzing with Bears”. These categories can be used to form the structure of a Risk Board – a tool you can use to track progress against agreed response activities. Michelle Sliger has also offered up some thoughts on this subject in her article: Relating PMBOK Practices to Agile Practices–Part 3 of 4.
- Mitigate
- Avoid
- Evade
- Contain
Mitigate
This response seeks to reduce the impact of a disruption should it occur. The greatest example of how Agile teams employ risk mitigation techniques is via their use of ‘Velocity’ as a way to reduce the risk of estimation uncertainty. With that said, velocity assumes a degree of predictability in order to work. It therefore needs to be adjusted to accommodate varying degrees of risk.
For example, in my post about minimising the impact of Sprint disruptions, I introduce the use of Stretch Tasks as a way to manage expectations about delivery capacity – i.e. the team commits to less but has a number of additional User Stories waiting in the wings for them to consume in the event the risk is not realised.
Avoid
As the name suggests, to avoid a risk describes a scenario where a project or a part of a project is cancelled in order to remove the threat of realisation.
As described above, the Product Manager will often remove a User Story or amend a requirement in order to reduce or remove an element of risk. The identification and assessment of these risks will take place during the Requirements Workshops, Planning Poker sessions and in Sprint Planning itself – Development teams will not generally accept high risk User Stories into a sprint.
Contain
To contain a risk describes a situation whereby you agree to deal with it as and when it occurs. These risks tend to be low(er) impact and/or less likely to occur thus not justifying any drastic action in advance.
On the other hand, it may be decided that the impact associated with mitigation or avoidance would have a greater negative impact than the realisation itself. In other words – you are prepared to take the risk.
It’s worth noting again that risks can in some instances have a positive impact – e.g. the risk of over-estimating a User Story may result in a team being able to complete a sprint early. The containment response may be to deliver a high priority User Story that had been lined up for the next sprint.
Evade
To evade a risk means to take no action at all. The risks which warrant this type of response are likely to be low impact risks, whose realisation would have little to no effect on project or company objectives.
Alternatively, some companies/teams may not be able to affort to respond any differently i.e. they need to take a chance! This has the potential to be a rather dangerous response albeit the least expensive.
The next step in the Agile Risk Management process is Risk Review.
Subscribe to the Agile101 RSS to be notified when I upload new Articles Templates and Tips!
Related Articles:
Agile 101 