Agile projects are primarily focused on maximizing business value. Risk is inversely proportional to value therefore it is in the best interest of an Agile team to do all that is required to avoid, eliminate or mitigate risk.
Since Agile’s primary focus is value, the importance of the relationship between risk and value on an Agile project cannot be over-emphasized. When a risk actually occurs, it decreases value by taking time and resources away from the project thus negatively impacting the project. For this reason, Agile teams plan to deliver the highest priority features early (maximizing value) while also implementing risk avoidance and mitigation early.
In an Agile environment, risk is a possible event or situation that could have an undesirable impact on the project. Unlike the PMBOK’s definition of risk that includes “good risks” also known as opportunities, Agile regards risk from a negative perspective as it threatens value; Agile’s all consuming passion.
It is important that all relevant project stakeholders are involved in the process of risk identification. The ideas from stakeholders, the lessons learned from past projects, the risk logs and industry risk profiles should all be used to design a comprehensive list of the known and probable risks for the project. It is safe to say that the development team is the most crucial to the risk analysis process. Because of the depth of their involvement in the project and their closeness to the technical details, they possess the greatest understanding of the potential project risks than any other stakeholder. Consulting the development team will also result in their commitment to the risk management plan and accompanying responses.
One of the many benefits of the Agile methodology is that there are a lot of opportunities to attack a risk before it becomes a problem. Agile’s use of iterative development enables high-risk activities to be addressed early on in the project. High risk features are consequently tackled in early iterations/sprints to prove the technological approach and eliminate doubts. While planning each work cycle, Agile projects work on high risk areas first so this can be resolved upfront rather than later on in the course of development. This helps to ensure that the issues are identified while there is still an opportunity in the schedule and budget to resolve them. This also helps to reduce the effort invested in work that may turn out to be waste.
The tools primarily used by Agile teams to manage risk are the risk-adjusted backlog, risk severity and the risk burndown chart. These tools help Agile teams to integrate and prioritize risk response actions into the backlog of development work.
The Risk-Adjusted Backlog
While planning each iteration, Agile teams try to balance delivering the highest priority features while simultaneously mitigating the biggest risks on the project. This the Agile team achieves by moving the items with the highest value and risk to the top of their backlog. Initially, the backlog might just be a list of the business features involved in the project, however, once the risk responses are included and prioritized (based on their negative value), it is then referred to as a risk adjusted backlog. This prioritized list is what enables Agile teams to focus simultaneously on value delivery and risk reduction activities.
Most projects simply prioritize their backlog based on the customer’s business value and perceived risk level of the different features to create the risk-adjusted backlog. This could however be more technical and hence more reliable. A better way to determine business value is by using the return on investments per feature. This starts with the financial return expected from the whole project. Once we have a figure, the business representatives, prorate the amount across the different features. Once this is completed, the features can then be prioritized based on the broken down business value. The next step is to monetize the risk avoidance and risk mitigation activities. We can use the EMV (Expected Monetary Value) for each risk to arrive at this figure.
EMV (Expected Monetary Value) = Risk Impact ($) x Risk Probability (%)
It is important to note that we are only looking for relative and not precise figures. We should not get bogged down by the level of accuracy of these figures at this point. We should however be more interested in arriving at figures that the stakeholders find justifiable and which can then be used for prioritization.
Assigning a monetary value to both functional and non-functional requirements enables the project team to have a meaningful conversation with the customer as it makes it easier for the customer to visually relate the business value to the associated risk involved. The risk-adjusted backlog is a tool that utilizes calculations to arrive at the priority of the work items to be completed. It also helps the Product Owner and the development team to have useful conversations on schedule and scope-trade-offs. Please find below a sample risk adjusted backlog.
Risk Severity
As the project progresses, the team should continue to monitor risks and measure the effectiveness of it’s risk reduction efforts. This the team can do using the concept of Risk Severity. To calculate risk severity, rather than using a risk’s probability percentage and dollar impact, we rank it’s probability and impact as low/medium/high then we multiply the probability and impact rankings to calculate the risk’s severity.
Risk Severity = Risk Probability x Risk Impact
Please note that the inputs here are only rankings; there are no monetary figures. While some projects might require detailed risk analysis based on EMV, most Agile projects are interested in relative risk profiles and trends. All that is required for that is the abstract value of risk severity based on a three-point scale which will produce severity scores that range from 1 to 9.
The team starts this process by doing an analysis of risk so that a probability and impact score can be assigned to each risk. Once that is completed, we use the scores to calculate the severity of each risk. Please find below a sample risk severity matrix.
Risk Burndown Graphs
To manage the long list of risks and issues associated with most projects, Agile uses a tool known as the Risk Burndown Graph. This tool is in keeping with Agile’s preference for fast, visual and easy to understand communication. To make the team’s risk data easy to understand, the numbers can be converted into a risk burndown graph. Please find a sample risk burndown graph below.
A risk burndown graph is a stacked area graph of cumulative project risk severity. The severity scores for each of the identified risks is plotted one on top of the other to capture the project’s cumulative severity profile. If risks and their severity are captured in this manner, it becomes easier to understand the overall risk status and trends of the particular project. One of the many benefits of a risk burndown graph is that new and escalating risks are easier to spot on the graph. Risk burndown graphs also serve to quickly show stakeholders the status of the risk; if it is decreasing or escalating. Risk burndown graphs are easy to understand and can be produced using Microsoft Excel.
On a final note, bearing in mind the fact that Agile projects are primarily driven by value, and that value in turn, is inversely proportional to risk, it is safe to say that an effective Agile team must take proactive steps to manage its risks with the intention of maximizing the project’s value.