What is a risk-adjusted backlog?

The risk-adjusted backlog is a sprint or release backlog containing risk response tasks for actionable risks. For negative risks, these actions include avoiding, mitigating, and transferring. For positive risks, they include exploiting, enhancing, and sharing.

For both categories of risk, it is also possible to accept risks that do not have a better solution. Acceptance can be either active or passive. Active acceptance of risks means creating a risk contingency reserve in terms of time, cost, or scope, and using this reserve to deal with risks as they occur. Passive acceptance means doing nothing about the risks at the time and dealing with them if they are realized.

Several approaches can be taken to prioritize risk responses. One is to categorize based on feature priority. For example, a risk affecting the top-priority task would take on higher priority than a risk affecting a task at the bottom of the backlog. Another way, suggested by Griffiths, is to use Expected Monetary Value, or EMV (Griffiths, 2011, 20 September). In the EMV approach, risk action is prioritized by the EMV of the risk. For example, if two risks each had a 25 percent chance of occurrence, but one cost $50,000 while the other cost $10,000, then the first risk (EMV is 25% of $50,000, or $12,500) would have a higher priority response than the second risk (EMV is 25% of $10,000, or $2,500).

Using EMV makes categorizing the opportunities, or positive risks, easier. When prioritizing risks based on feature priority, choosing whether to emphasize a threat or opportunity can become a judgment call. EMV helps reinforce the decision with mathematical backing. If one feature has an associated threat with a 30 percent chance of occurrence that would cost $10,000, and an associated opportunity with a 40 percent chance of occurrence that would gain $10,000, then the opportunity is slightly more valuable ($4,000 gain versus $3,000 loss) Risk appetite also comes into play; if it is more important to avoid losses, then the $3,000 loss might still be prioritized. Either way, using EMV introduces more data into the decision-making process.

Figures 1 and 2 are examples of a risk-adjusted backlog for a sprint, as well as a risk burndown chart to show how the risk decreases over time. In the example presented in Figure 1, the response tasks for the risks add 30 story points to the sprint, increasing it from 81 story points to 111. In figure 2, severity is on a nine-point scale, with a probability and impact of 3 being the highest possible for each.

Figure 1. Risk-Adjusted Backlog

Figure 2. Risk Burndown Chart

Best Practices

1. Considering risk-based spikes.

In Agile, a “spike” is a short proof of concept to investigate an issue further. Some of the reasons behind spikes include testing different methods to achieve the same result, as well as testing to confirm that the desired result is attainable through the current project approach. For example, a team might perform a spike to see if they can code an application in one language as opposed to another. A risk-based spike is a spike carried out in response to a known risk. These can also be opportunities or threats. The team might find out that using a different programming language can speed up development, or they might find out that they can’t use the one they had planned to use. These spikes would be added to the backlog as mitigation actions.

Risk-based spikes are useful because they can often lead to “fast failure.” In other words, a team can use a risk-based spike to discover that the approach they planned out will not work and they need a new approach. This discovery may seem like a huge problem at first. However, the sooner this problem is discovered, the sooner it can be corrected so that the team can return its focus to delivering value to the customer.

2. Building risk into the estimation process.

When estimating stories, teams should also keep risks in mind. In fact, an estimation session can be a good place to record information about risks that would cause one story to be estimated higher. For example, if three team members rate a story an “8” in terms of story points, another team member might point out that if there are problems with a scheduled upgrade, the story could easily be 20 story points. This conversation would prompt additional discussion as to how the team can prevent the story from being 20 points, generating potential risk response tasks for the backlog.

3. Keeping the risk-adjusted backlog up-to-date.

As part of the backlog grooming process during and between sprints, the team should make sure that any risk-adjusted items in the backlog are updated as the risks approach. New information can affect the probability and impact of risks, so keeping this information up-to-date is a key part of keeping the risk-adjusted backlog relevant.

Failing to update the risk adjustments presents both risk-related and communication-related issues. First, by failing to update risks means that the team could be missing out on a new risk. Second, failing to update risks means that existing information about risks has not changed even if the risks themselves have lessened or gone away. Stakeholders may get the wrong idea about risks if the risk contingency reserve shows high levels of remaining risks even in the middle or end phases of a project. To make sure that the risk-adjusted backlog is communicating the correct amount of risk for the project, make sure it stays updated.

Pitfalls

1. Failing to account for all risks.

On any project, not just agile projects, it is important to make sure that as many risks are documented and planned for as possible. Missing a risk can mean missing out on an opportunity to save money and time, freeing up more resources to add value to the customer. It can also mean missing out on a threat that would rob the project of value by requiring rework or brainstorming a new approach. Risks that are not planned for could be catastrophic to the point of causing project failure. Some risks, like natural disasters, may not have much of a response other than to be accepted, but they still need to be known.

2. Not involving the right people.

One key piece of getting all risks recorded is involving the right people in risk planning. For an agile team, that might mean reaching out to others in the organization who are not on the team but can provide insight into risks that threaten the team’s goals. Others in the business who can provide input include product managers, executives, and testers. It’s important to get a wide variety of insights into possible risks. For example, the product owner can provide risks from a business standpoint, while the ScrumMaster can provide risks based on his or her perception of how closely the team is following methodology.

Teams can also look to historical information and lessons learned from previous projects to find more insight into possible risks to their release and sprint goals. Ideally, lessons learned should incorporate all members of the team in order to provide the most value. In agile methodology, teams drive much of the process, which makes it important that they know when to seek additional guidance identifying possible risks.

3. Failing to discuss risks regularly.

Agile gives a team plenty of opportunities to communicate key information about the project, including release and sprint planning meetings, daily scrums, sprint reviews, and sprint retrospectives. Any of these ceremonies presents ample opportunity to discuss key risks on a project and get the latest information. Having the latest information allow a team to take action as needed. In daily scrums, it is typical to ask team members if they have any issues or barriers facing them. Including risks at this time is a good way to get updates and plan necessary responses.

Conclusion

Risks are just as important to identify and deal with on an agile project as they are on any project. Fortunately, there are many tools available to help with agile projects as well. In addition to the risk-adjusted backlog, there is also the risk burndown chart, another popular tool, which is similar to the sprint burndown chart, but instead shows the impact of risks over time. Whether teams use a burndown chart or add risks to adjust their backlog, performing risk management is a key part of ensuring that the customer is receiving value.

If you are looking for further assistance, or have a specific roadblock you need to get around, we’re happy to help. We can help your team successfully implement Agile, or get back on track with Agile with a little bit of coaching or training. Download our Risk-Adjusted Backlog template and get in touch with us about any Agile challenges you are facing. We also welcome you to set up a call with us.

References

1. Griffiths, Mike (2011, 20 September). The game of risk. ProjectManagement.com. Web.