The nature of an Agile Project is geared towards Managing Risk within a Risk Management Process. The Riskiest Work is tackled first, in a short and Manageable Work Package, the Sprint. As each subsequent Sprint is tackled, the Work to be finished ends up being progressively less Risky. Confidence levels in the Project increase.

Does an Agile Project need a Formal Risk Management Process?

On the occasion that the Project is not Working, it can be halted at the end of the Sprint. An evaluation is be performed and a decision taken whether to cancel the Project or continue after applying some extreme Changes. From this viewpoint, it can be stated that Risk Management is inherent in every Agile Project. This is why many advocates of Agile feel that adding a Risk Management Process to the Project is unnecessary. Where a Project is complicated and there is an great deal of unpredictability in the viability of the Product to be Developed, there is nothing to be lost in applying Traditional Risk Management Principles.

The Risk Management Process & Building a Risk Register

Risk Management and the associated Processes are commonly used in many Business systems. The Principles of specifying a Risk and Prioritizing it ought to be known to the Scrum Team (Scrum Master, Product Owner and Development Team). In the event where they have never taken part in a Risk Meeting before, it may be necessary to discuss the following standard Concepts to the Development Team members.

• the distinction between a Risk (something that might occur) and an Issue (something that has happened and needs to be Managed).
• ‘ Probability’ – the possibility of a Risk ending up being an Issue, expressed as a percentage.
• ‘ Impact’ – the severity of the repercussions if a Risk is not alleviated. Typically, this is a number in between 1 and 10, representing Severity.
• The Risk Rating or Risk Exposure. This is the Value returned in the equation:
  Direct exposure = Probability * Impact.
• ‘ Mitigation’ – the actions to be taken to decrease or eliminate a Risk.
• ‘ Ownership’ – A Risk is generally designated to a Risk Owner, whose Job it is to ensure that the Risk does not turn into an issue.
• ‘ Risk Register’ – a list of Risks, Probability, Impact, Exposure and Mitigations. This register is reviewed weekly as the exposure of the Risks must Change on a regular basis. Ideally, the exposure should reduce, but if it increases, it might be necessary to take some evasive action.

Risk Register

There are other fields that can be included on a Risk Register, such as class of Risk (e.g. monetary, reputational). If your Company has executed Enterprise Risk Management or uses a standard for Risk Management, such as ISO31000, you should naturally adopt that Framework or practice.

The Register can be displayed in a prominent location, for all to see, together with a Risk Burndown Chart

Guaranteeing Transparency: The Risk Burndown Chart.

An Agile Project requires the utmost openness in any Project. This applies especially to Risks, where they are being itemized in a Risk Register. The Risk Register can be circulated and/or pinned to the Project Board for all to see.

In 2004, John Brothers formulated the Risk Burndown Chart as an alternative Method of Illustrating Project Risk. The Chart plots the overall direct exposure against the Sprint number.

Who is accountable for the Risk Management Process?

As Agile does not clearly describe a Risk Management Process, there is some debate as to who owns the Process. There is no arrangement made for a Risk Meeting. However it fits quite well into the established Meetings, specifically if Agile Scrum has been embraced.

The very first Sprint Planning Meeting is the ideal Opportunity to list Risks. These can then be used to construct a preliminary Risk Register. An initial Risk Meeting can be held subsequently to the very first Sprint Planning Meeting.

We found these books great for finding out more information on Agile Scrum:

SMEs (Subject Matter Experts) must be invited who can aid with examining the Risk and recommending Mitigations. The Risk Register can be updated and an initial Risk Burndown Chart can be charted.

The Risk Management Process & the Risk Register

A couple of minutes need to be provided to talking about the Risk Register during the Daily Standup Meeting. Throughout the Standup Meeting, prospective Risks are identified as a matter of course, and they can be included to the Register for Tracking.

At the end of each Sprint comes the Retrospective Meeting. The Risk Register can be used here to advise everyone of the Project Risks that were experienced and any Lessons that can be Learnt from how they were Managed during the Sprint.

The ease with which Risk Management can be integrated into the routine Scrum (or other Agile Framework) processes shows that there is a location for standard Risk Management in Agile Projects. Most Stakeholders will be familiar with Risk Management procedures and reporting and will understand the contents of the Risk Register, and what its implications are for the Project, while they might be challenged by some of the other details readily available, such as the Sprint Burndown Chart. The team might come to grips with the Concept at first, but Risk Management has a brief Learning Curve. What is more, it is a skill that can be used generally, so the Team members should be eager to Learn the Principles.