Get certified - Transform your world of work today


Risk and Issue Management in the Scrum Process

16 April 2014

Sanni Babu Yegi
Cybersoft Technologies Inc

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
  1. Prevent the realization of a risk, or
  2. 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 identification
  • Agile risk assessment
  • Agile risk response
  • Agile risk review

Agile risk management -- identifying risks

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.

Requirements workshop

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.

Planning Poker

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

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.

Sprint review

This session also provides an opportunity to highlight successful mitigation activities -- it's good to keep your stakeholders informed of what's going on.

Sprint retrospective

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:
  1. What went well during the last sprint? This could be the successful handling of a risk.
  2. What didn't go so wel? This could be the realization of a risk or the reoccurrence of an issue.
  3. What will we do differently in the next sprint? This could include risk mitigation activities.

Agile risk management -- assessing risks

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.
  • 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).

Agile risk management -- risk response

There are four different categories of risk responses:
  • Mitigate
  • Avoid
  • Contain
  • Evade

Mitigate: 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.
Avoid: 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.
Contain: 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.
Evade: To evade a risk means to take no action at all.
  • 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.

Agile risk management -- risk review

Risk review is the final stage in the Agile risk management process. The "review" stage in the risk management life cycle is threefold:
  • 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

Agile issue management

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
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."

Issues snake
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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (9 ratings)


Jaishankar Madamshetty, CSM, 4/18/2014 10:16:20 AM
Hi, I apreciate the way you explained to manage risks, but this explains the starategies for negetive risks only, but there could be positive risks (opportunities) and we should identify strategies to enhance or increase the probability of occurance of these positive risks. You could have explained this as well. Anyway nice article on risk management. Thank you
Sanni Babu Yegi, CSM, 4/23/2014 1:48:30 AM
Thank you for the comment Jai..
Santosh Kumar Dwivedi, CSM, 10/24/2017 3:24:29 AM
Well said Jai.
Normally, when people refer to risks,they talk about threats only. Opportunities are normally not managed like risks (i.e. to take steps to enhance their likelihood)

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up