Agile & Risk Management: Managing Risk Via the Product Backlog

This blog is the fifth in a series about agile and risk management. The first four blogs are:

1. “Three Key Agile Risk Management Activities”
2. “Agile & Risk Management: The Mental Model of Uncertainty”
3. “Agile & Risk Management: Antifragile”
4. “Agile & Risk Management: The Role of Traditional Risk Management”

In this blog I discuss the role of the product backlog in managing risk during agile product development.

Risk as a factor in prioritization

The product backlog is a prioritized list of the features and other capabilities needed to develop a successful product. Items in the product backlog are ordered so that the high-value items appear at the top of the product backlog and the lower-value items appear toward the bottom.

As shown in the above figure, there are many different factors that can and should be considered when ordering the items in the product backlog.  Six common factors are:

• Value – as a first approximation we should work on items of greater customer value before items of lower customer value
• Cost – the cost of an item can and should affect its priority. Without considering cost we can’t fully quantify the economics of our prioritization decisions
• Knowledge – there are times when the next most important action for us to take is to buy some knowledge to help reduce the uncertainty we have
• Dependencies – often times an item in the product backlog has to be placed after one or more other items on which it is dependent
• Resources – a particular item might require a special resource (e.g., person or equipment) before we can work on it
• Risk – the highest priority work at a given time might be performed specifically to address a known risk

Let me expand on the risk factor. Although we won’t be able to identify all risks, there are certainly some that we can. For the known risks we need to decide how and when to address them. In the context of our mental model of uncertainty, we need to identify candidate actions and when we plan to take them. (The timing is represented by the actions’ positions in the product backlog.)

I operate by a very simple rule. Attack the high-risk items before they attack me. So, if there is a risk that has a high probability of occurrence, and is very costly if it occurs, then I am going to consider candidate actions that have reasonable costs and move them towards the top of the product backlog.

Let me illustrate three examples of how risk can influence the product backlog.

Example 1: Using risk as a prioritization factor

Let’s say we are developing a system (perhaps an email system) that needs to scale to 10 million concurrent users. Assume also that we have never developed any system that has ever had to scale to 10 million users. How should we proceed?

Option 1

One option is to spend a lot of money early on to develop core and advanced email features. Then, when we are about to go live with the system, let’s perform scale-up testing to see if it works for 10 million concurrent users!

This option would be risk generating and not risk reducing. We certainly don’t want to learn late in development that the system can’t scale to 10 million concurrent users (instead it only scales to 100,000). This might lead to total system failure.

Option 2

The second option acknowledges the fact that since the risk of not being able to scale to 10 million concurrent users is high (especially if we have never done it before) it therefore can be considered to have a high probability of occurrence. Also, the cost of being wrong could be very high if we don’t determine early on whether we can or cannot scale to that load.

So, to address this risk we would reprioritize the backlog to run a series of tests as early as we can to determine if scaling to 10 million concurrent users is possible. Only when we have a good grasp on our ability to scale to a very large load would we have the confidence to build the email features. Notice in the figure for Option 2 that the scaling risk-reduction work is higher in the product backlog than the email features.

Example 2: Managing Dependency Risk via Product Backlog Grooming

The picture below shows a product backlog with lines drawn through it. I refer to this artifact as a sprint map. In this simplified example, the lines are drawn based on the team’s average velocity (in this case 20 points/sprint). So, every 20 points or less, we draw a line to show what might be completed in Sprint 2, Sprint 3, etc. down to some reasonable depth in the product backlog.

Let’s say that Feature L (the highlighted feature) has a known dependency. For example, we outsourced development of a component to a vendor and it really doesn’t make any sense to start working on Feature L until we get the vendor’s component (or we would block immediately).

The first question we would ask the vendor is when will we get the component? The vendor will answer us with a calendar date. The good news for us, since we do fixed-length sprints, is that as soon as we get the date from the vendor we know in precisely which sprint that date will occur.

So, for example, if the vendor forecasts a completion date near the end of Sprint 3, we would conclude that Feature L is a candidate to be worked on in Sprint 4. We would make the decision as to whether or not we should do Feature L in Sprint 4 at the last responsible moment, which would be the Sprint 4 planning meeting.

The important point in this example is that we can use the product backlog as a means of communicating and managing important dependency risks.

Example 3: Managing Risk by Creating Risk-mitigation Items in the Product Backlog

As a final example, let’s look at how we can mitigate important risks by creating new product backlog items.

Let’s reuse the domain of the previous example—we outsourced development of a component to a vendor and there is a risk that the vendor will not deliver the component when promised.

One way to address this risk would be the “parallel hedge” strategy. Basically, if the cost of delay from not getting the component on time is very high, we might start a parallel development effort to create the component ourselves (see the image below).

Us starting to develop in parallel would require that we create product backlog items representing work to develop the component. Those product backlog items must then be appropriately ordered in the product backlog. And, whoever finishes the development of the component first (us or the vendor) wins!

So, in this example, we inserted new product backlog items (candidate actions) to address a known risk with significant consequences.

Conclusion

The product backlog is the prioritized list of work that needs to be completed to achieve success with our product development effort. Risk is used as a factor to influence not only the order in which items appear in the product backlog, but also which items might be included. 

This blog addresses the first of three principal approaches to risk management inherent in agile development.

1. Manage risk via the product backlog
2. Applying agile properly to avoid some uncertain situations (to eliminate the possibility of uncertain events)
3. Apply core agile principles as a fundamental way to address uncertain events

In the next blog in this series I will discuss the second of these three approaches: applying agile properly to avoid some uncertain situations.