What is a risk?
A risk is an uncertain event that could impact your chosen path should it be realized. Risks are events that are not currently affecting you -- they haven't happened yet. Once a risk is realized, it has the potential to become an issue.
Aim of risk management
Prevent the realization of a risk, or
Minimize/manage/neutralize the impact of this risk once it has been realized.
If you succeed in point 2, then the net impact of realizing the risk may be totally acceptable, i.e., no issue at all.
Risk management for projects
Agile risk management -- identifying risks
Agile risk identification
Agile risk assessment
Agile risk response
Agile risk review
In Agile environments, the team shares responsibility for identifying risks that might affect a sprint, project, or program of development.
The Scrum meetings provide a strong forum for identifying risks on a daily basis.
The team and the product manager discuss new ideas and a rough idea of the effort required to deliver them. This conversation allows the product manager to reconsider and/or adjust requirements in a way that maximizes value and minimizes risk/uncertainty.
Here the team estimates the relative size of each user story. This is yet another opportunity for a product manager and a team to reduce risk by rejecting user stories that are over a certain size – they're broken down into smaller stories.
Scrum of Scrum
In this session, we review project-level progress, risks, and issues. The session is attended by the ScrumMaster(s), product manager, and product owner(s).
Sprint planning is yet another opportunity for the team to identify, assess, and respond to risk. They only accept work they feel confident about delivering.
The Daily Scrum
Once the sprint has commenced, the Daily Scrum becomes the main forum for raising risks and issues. We ask the question, "Is anything blocking you or likely to block you from progressing as planned?"
We add highlighted risks to the risk board and catch up with the individual after the Daily Scrum to gather more details.
This session also provides an opportunity to highlight successful mitigation activities -- it's good to keep your stakeholders informed of what's going on.
Retrospective discussions will focus primarily on the idea of continual improvement, and risks can be unveiled at this session.
The key questions answered at a retrospective are:
Agile risk management -- assessing risks
What went well during the last sprint? This could be the successful handling of a risk.
What didn't go so wel? This could be the realization of a risk or the reoccurrence of an issue.
What will we do differently in the next sprint? This could include risk mitigation activities.
We use two measures to describe a risk:
The probability/likelihood of it being realized
The impact it will have if it is realized
We assess risks based on their severity. Let's take 1 being low impact/likelihood and 5 being high impact/likelihood.
Agile risk management -- risk response
A user story is severely underestimated in the first sprint, compromising the team's ability to deliver on their commitments (1,5).
A user story is severely underestimated in sprint 10, compromising the team's ability to deliver on their commitments (5,1).
There are four different categories of risk responses:
Agile teams employ risk mitigation techniques via their use of velocity
They stretch tasks as a way to manage expectations about delivery capacity.
The team commits to less but has a number of additional user stories waiting in the wings for them to take on in the event the risk is not realized.
This describes a scenario in which a project or a part of a project is canceled in order to remove the threat of realization.
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.
To contain a risk describes a situation whereby you agree to deal with it if and when it occurs.
These risks tend to be low(er) impact and/or less likely to occur.
On the other hand, it may be decided that the impact associated with mitigation or avoidance would have a greater negative impact than the realization itself. In other words, you are prepared to take the risk.
To evade a risk means to take no action at all.
Agile risk management -- risk review
The risks that warrant this type of response are likely to be low-impact risks, whose realization would have little to no effect on project or company objectives.
Risk review is the final stage in the Agile risk management process. The "review" stage in the risk management life cycle is threefold:
Agile issue management
Reviewing active risks to ensure that responses are delivered in a timely/efficient manner
Reviewing the risk management process to ensure that it is optimized
Reviewing the impact of risks and risk realization on project and company objectives
Scrum is great at handling immediate issues more commonly referred to as "impediments." The team raises these issues daily via the Daily Scrum. Some teams like to keep track of all of these impediments by using an "issues snake" or an "issues calendar."
How this works
Every time an issue is raised at the Daily Scrum, you write it on a post-it and place it somewhere visible.
If the same issue is raised more than once, you add another post-it-note to the board.
This helps keep track of blockages and disruptions and can be used to drive conversation at the end-of-sprint retrospective or at the end-of-sprint review.
This approach also helps you to quickly identify reoccurring issues or blockages.
Issues calendars are particularly useful as you can compare them to the team burn-down to better understand velocity variances, e.g., "The team burn-down suffered on that day as they were dealing with a particularly hefty impediment."
This is another way of maintaining the daily issues:
Agile issue management versus traditional issue management
Agile issue management is built into the delivery process, e.g., via the Daily Scrum.
The team works together to raise and clear issues.
Documentation is kept to a minimum -- all energy is put into clearing the issue.
The team regularly reviews their issue management approach in hopes of improving their handling techniques.