Managing risks in Agile projects

Agile Risk Management

Managing risks in Agile projects

Managing Risks help us to identify potential problems before they occur, so that risk response can be planned appropriately and acted upon as per the plan in order to eliminate the risk or reduce the likelihood of risk and/or to reduce the impact of the risk or to act on the risk when it occurs.

Risk is an uncertain event, that can alter the outcome of the project in a positive or negative way, where as issues are those events that are occurring or have occurred and affect the achievement of project objectives negatively

Risk Management in Agile Projects

We can manage risks in projects by associating user stories to epics/themes and ensuring that risks are prioritized early in the project’s iterations. The goal of each iteration should be to progressively ‘de-risk’ the project

Risk Management in Project

Note: Risk Management process to be repeated in every iteration.

As a part of the iteration retrospective, we should review the remaining risks and validate the probabilities and impacts. Also ask the team to identify new risks. The remaining features that continue to carry risk would be identified for selection in the next iteration

Risk Management in Project 2

Risk Adjusted Product Backlog

Risk involved with a feature is an important factor in the prioritization of the product backlog. The PO, along with Dev team, prunes the backlog. While pruning, impact (risk) analysis is the key: items are broken down, analysed for their interdependencies, shifted up or down in priority, re-estimated, removed, and reallocated to iterations or releases. Analysing the impact of changing requirements should be a routine among successful agile teams.

Risk Adjusted Project Backlog

Risk Management Lifecycle

Below are the four steps in risk management lifecycle:

  • Identify
  • Assess
  • Respond
  • Review


There are several techniques to identify the risks in which brainstorming is the one which I’ll prefer as all the team will involve and discuss and identify the risks involved.

Risk Identification

Brainstorming Process


So now I hope a question might have revolving in your mind to know when we need to identify the risks. Risk Identification can be done in below stages

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Risk Identification Opportunities


We will consider below factors for assessing risks

  • Probability of occurrence (p)
  • Business Impact (i)
  • Probability timelines of detection (d)
  • Correction capability (c)
  • Asset value (a)

Risk Assessment R = (a*p*i)/(d*c)

If R<=4  i.e., Low ; R<=8 i.e., Medium ; R<=12 i.e., High ; R>12 i.e., Very High


For every risk we identified, it is important to have a strategy to respond to it

Risk Responsive Strategies

In this risk response strategy, we will make sure the opportunity is realized. Here, we take the opportunity very seriously and develop a strategy to realize it.

E.g. Suppose if we are working on a mobile application development project, and suddenly the client tells us that if we complete the project a month before the actual completion date, he will give us extra business.

This is an opportunity for us to realize it. Therefore, we do everything to complete the project ahead of time. We’ll motivate team and requests them to give overtime, bring some more resources etc.


In this risk response strategy, we take measures to increase the chance of the event happening, but there will be no assurance of realizing this opportunity.

E.g. Suppose if we are working on a mobile application development project, and suddenly the Management tells us that if we complete the project a month earlier than planned, they will give a star award. Therefore, we take several measures to realize the opportunity.

As you can see in the above example, we’re only trying to complete the project early to gain the opportunity; i.e. we are only increasing the probability of completing the project early; there is no guarantee that we will realize the opportunity.


In this risk response strategy, we will cope-up with another company when we are not capable of realizing the opportunity.

E.g. Suppose if we got a mobile application development project, and we don’t have an expert in that domain and management don’t want to miss this project / customer. So now due to lack of technical abilities we will team up with another company to deliver the project successfully.

Here we are using the share risk response strategy because the profit will be shared between both parties.


This risk response strategy is common for both type of risks; i.e. positive risks and negative risks.

For Positive Risk – In this accept risk response strategy, we’ll not take any action to realize the opportunity. We’ll leave the opportunity as is, and if it happens on its own, we will benefit from it. We will use this risk response strategy when the cost of the response is high and there is less of a chance of it occurring or the benefit does not outweigh the effort involved.

For Negative Risk – In this accept risk response strategy, we’ll not take any action to avoid the threat. We’ll leave the threat as is, and if it happens on its own, we will face the consequences. We will use this risk response strategy when the cost of the response is high and there is less of a chance of it occurring or the threat does not outweigh the effort involved.

E.g. Suppose there is a chance we may get some skilled resources from another project at a lower rate if we convince them to join us. However, we do not pursue this matter and instead let them decide whether they are interested in our project or not.


In this risk response strategy we’ll try to eliminate the risk or its impact. We do this by changing our project management plan, by changing the project scope, or by changing the schedule. This is a desired risk response strategy mainly used for critical risks. This is the best technique for all risks; however, it cannot be used most of the time. It is easy to use this strategy if we identify the risk in a very early stage, otherwise it is difficult to adopt this strategy because in a later stage changing scope or schedule is a costly affair.

To use this strategy we’ll have convince the client and/or our management to change the scope or schedule. We can only utilize the avoid risk response strategy after their approval.

E.g. Suppose we are working on a project where we will be required some vendor services. There is a chance of vendor missing d outdoors at that time. Therefore, to avoid this risk we move these activities to a few days later to avoid the impact of rain.


Mitigation is the most common risk response strategy and is certainly the one people use the most. Here we will come up with actions which will make the risk impact less.

E.g. if testing phase is taking too long, we can add more testers to our resource pool. The risk still might happen, but at least we have done something to make it less impact.


We’ll use this risk response strategy when we are lacking skills or resources to manage the risk.

Using this transfer risk response strategy, we transfer the risk to a third party to manage it.

Note: Transferring does not eliminate the risk; it only transfers the responsibility of managing the risk to the third party.

E.g. Suppose in our project there is a task to install some servers and we have little experience with this task. Therefore, we find a contractor and ask him to install it.

In this way, we have transferred the responsibility of the whole task to a third party, and now it is his responsibility to complete the task within the agreed time and cost.


Risk review is the phase where we meets for reviewing the risks. Here we should review the active risks to ensure that deliverables are delivered in a timely and efficient manner, generally done through the daily scrum. During every sprint meeting, the risk register must be reviewed and updated with any new information obtained over the sprint. This way our risk management becomes an integral part of Agile.

Share this post

Comments (2)

  • Sujith Soppa Reply

    Nice Article and was extremely thorough, comprehensive and well thought out.

    November 19, 2018 at 7:49 am
    • admin Reply

      Glad you like it 🙂

      November 19, 2018 at 7:52 am

Leave a Reply

Your email address will not be published. Required fields are marked *