Risk Management in Agile Environment

January 25, 2016


In Agile methodology often Risk Management is not given much of priority because of the following reasons:
1.    The Whole development is broken down into shorter Sprints which are normally 2 weeks
2.    There are several tasks at each sprint and in case the Risk for implementing the Task is high it can be pushed to a future sprint or omitted altogether
3.    The Risk prioritization is some time conflicting with different team members assigning different Probability and Impact parameters
4.    Resource is a problem as most of the Team members are doing multi-tasking and it is difficult to assign a specific person as the Risk Owner
5.    Lack of consensus on the Risk Communication – which Risk needs to be communicated at and up to what level
6.    As Agile does not advocate much of documentation so Risk Management Plan creation is considered as an overhead. Also it is not considered as Customer Deliverable.

However even by keeping all these in mind one needs to invest some time and effort in identifying Risks and planning for responses. This is to avoid any surprises. Also if a Risk is just identified and monitored at least the Management  can be communicated and updated early on, which will help the SCRUM Master and the team to cushion themselves in case the Risk occurs. 

The Risk Register should be created with may be fewer elements as suggested by John Cohn in his book “Agile Times”. This should only have the Risk Description, Probability, Impact (Size of Loss) and exposure. 

Risk                                                                                                                              Probability    Size of Loss    Exposure
Mismatch in Code impacting the build process                                                             60%           5 Days                 6.0
Prototype has some lacuna and it is discovered during implementation                 70%           8 Days                 7.5
APIs are not working properly and third party systems could not be accesses       60%           6 Days                 6.5
Usability issues on different UI platforms                                                                       40%           4 Days                 5.0
Server integration issues                                                                                                    45%           5 Days                 4.0
                                                           Total                                                                                                                             29

This risk register needs to be re-evaluated during and at the end of each sprint and the exposure value will be updated. For the Tasks with risks which are completed can be nullified, also New Risks can be added. This will show something like the below table:

Sprint    Exposure
1                   29
2                   22
3                17.5
4                   19
5                   11
6                     8
7                     6
8                     1
Now this can be used to create the Risk Burndown Chart. This can be made as a part of the Weekly Status Report which is shared with all the Stakeholders. This will help the Sr. Management also to get a good view of how the Risks are tracked and mitigated.


This is a very basic approach to do Risk Management in Agile development methodology without much of extra documentation and overhead. Also it is better to display the Risks details and Burndown chart printout in the SCRUM Task Board beside the Tasks,  near the sitting area of the team so that everyone is aware of the present status.

Please reload

Featured Posts

Advantages of a Mobile App based Recruitment Tool

February 22, 2016

Please reload

Recent Posts
Please reload

Please reload

Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square

                                Privacy Policy                                     Terms of Use                                           Contact Us