How can an Agile Risk Register be used for Managing Risk in Agile Projects? There are lots of reasons that Companies are embracing Agile. They are embracing it both within their IT division and within other areas of business. Among the reasons is the Ability to “Fail Fast”. It might seem Counter-intuitive to invest time and energy in a Framework that hints of failure. However, in truth the capability to drop an unsuccessful Initiative at an early stage limits expenses and wasted time. Most of us have at least one “Death March” Project in our experience. These are projects that went on for many years past the Estimated completion date. Even where such a Project is Completed, the outcomes are often not what the Customer desired. The Requirements that were originally stated are far removed from what is Required today.

Does an Agile Project need a Formal Risk Management Process?

The nature of an Agile Project is tailored towards Managing Risk. The Riskiest Work is taken on first, in a short and Manageable Work Package, the Sprint. As each subsequent Sprint is completed, the Work to be finished becomes progressively less Risky. The confidence levels in the Project grows.

On the occasion that the Project is not Working, it can be stopped at the end of the Sprint. During a Sprint, an examination can be carried out and a decision taken whether to cancel the Project. Alternatively the project may continue after implementing some radical Changes. From this viewpoint, it can be said that Risk Management is intrinsic in every Agile Project.

From this perspective, it can be said that Risk Management is inherent in every Agile Project. This is why many supporters of Agile feel that adding a Risk Management Process to the Project is not required.

Constructing an Agile Risk Register: The Fundamentals

Risk Management and the associated Processes are commonly applied in many Business units within most Organizations. The Principles of specifying a Risk and Prioritizing it must be understood. Each of the Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) members must understand this. Where there is no previous Risk Meeting participation, it may be necessary to explain the Concepts to the Team.

• The difference between a Risk (something that might happen) and an Issue (something that has taken place and which now need to be Managed).
• ‘Probability’ – the likelihood of a Risk becoming an Issue.
• ‘Impact’ – the intensity of the consequences if a Risk is not alleviated. Generally, this is a number in between 1 and 10 expressing Severity. However you can also reveal Impact in other ways. These options could be the number of days to be lost if the issue takes place.
• The Risk Rating or Risk Exposure. This is the Value returned in the equation:
  Risk Exposure = Probability * Impact.
• ‘Mitigation’ – the actions to be taken to lessen or remove a Risk. Mitigations are best identified and described by a subject professional.
• ‘Ownership’ – A Risk is typically assigned to a Risk Owner. Their Job is to ensure that the Risk does not become an Issue.
• ‘Risk Register’ – a list of Risks, Probability, Impact, Exposure and Mitigations. The Agile Risk Register is reviewed weekly as the direct exposure of the Risks may Change regularly. Ideally, the exposure should reduce, but if it increases, it may be necessary to take some evasive action.

Risk Classes

There are other fields that can be included on an Agile Risk Register, such as class of Risk (e.g. monetary, reputational).

If your Company has implemented Enterprise Risk Management or uses a standard for Risk Management, such as ISO31000, you should naturally adopt that Framework or practice, rather than reinventing the wheel (and being out of alignment with the rest of the Business).

The Register can be shown in a prominent place, for all to see, together with a Risk Burndown Chart.

Agile Risk Register & 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. While the Risk Register can be circulated and/or pinned to the Project Board for all to see, there is an excellent graphical analogue you can use.

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

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

Agile Risk Register: Accountability in the Risk Management Process

As Agile does not explicitly explain a Risk Management Process, there might be some debate as to who owns the Process. The response is that the Team owns it and everyone in the Team must take turns in Maintaining and Publishing the Register. There is no provision made for a Risk Meeting, however it fits quite well into established Meetings, specifically if the Scrum Framework has been embraced.

Planning for Risks

The very first Sprint Planning Meeting is the perfect Opportunity to note Risks that are determined during or after breaking User Stories into Tasks. These can then be utilized to construct an initial Risk Register. Any items from the register that are addressed can be Reviewed during the Sprint Review Meeting.

A preliminary Risk Meeting can be held additionally to the first Sprint Planning Meeting.
SMEs (Subject Matter Experts) must be invited to help with evaluating the Risk and recommending Mitigations. The Risk Register can be upgraded and an initial Risk Burndown Chart can be charted.

The Daily Stand-Up & Project Risk

A couple of minutes ought to be offered to discussing the Risk Register during the Daily Stand-up Meeting. Throughout the Stand-up Meeting, potential Risks are recognized 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 utilized here to advise everybody of the Project Risks that were experienced and any Lessons that can be Learnt from how they were Managed during the Sprint.

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

The ease with which Risk Management can be integrated into the regular Scrum (or other Agile Framework) processes suggests that there is a place for Risk Management in Agile Projects. Most Stakeholders will be familiar with Risk Management protocols and reporting, and will understand the contents of the Risk Register, and what its ramifications are for the Project.