When teaching Product Owner workshops, I talk about the need to get a prioritized product backlog. For some students, this is easy but many people struggle. They’re used to fixed date/fixed scope projects so they regard all items as necessary. So everything is a must. But, as I tell them, some musts are more must than other musts. This always gets a chuckle but the fact remains – we need to have a ranked backlog for the team to work. While business value is the main one to use for ranking, sometimes risk can be a good factor to consider.

What is Risk?

as “something that creates or suggests a hazard”. When I first started my agile journey, we were creating a lot of new technology that was inherently risky. The question we had to answer was: how can we address risk and still make sure we’re delivering the right product functionality?

We decided to tackle this estimating the work and then providing a level of confidence in that estimate. Combining the confidence level and the business value provided a means for prioritizing our product backlog. This ensured that we worked our high-risk, high-value items first.

Calculating Risk

To calculate risk, we did something very straightforward. We used a table to create a basic formula:

risk level = confidence factor * business value factor

For the confidence level, an example we tried was:

And for our business value we tried this chart:

So, when we looked at a “high business value” (3), “low confidence” (3) item, our formula looked like this:

risk level = confidence factor (3) * business value factor (3) = 9

This was a good data point because it said that this functionality was highly desirable but we weren’t sure how to create the code to support it. For many teams, technical spikes are used to reduce risk on a story. That’s a lot harder if your entire technology stack and functionality has never been done before.

If we compare this against something that’s a must but we know how to do it, we might have:

risk level = confidence factor (1) * business value factor (4) = 4

It may seem odd ranking something that’s a high want higher than a must, but our goal was to reduce risk. We did play around a lot with the factors, trying to get the right blend. One way is to change the chart to value must and high want items higher than 4 and 3 respectively. Or you can simply ensure that your backlog contains all the must items before you work on anything valued lower.

Prioritizing the Product Backlog

One of the most popular methods for prioritizing work, whether it’s a feature set or a product backlog, is to use or WSJF. WSJF comes from Principles of Product Development Flow by Don Reinertsen and takes an economic view of the work. The intent is to provide an economic and objective view of the value of an item with an emphasis on the cost of delay (how much will it cost if we don’t do this). This can be very helpful when multiple stakeholders are engaged and avoids the “ugly baby” syndrome that commonly accompanies this.

WIth the risk approach, the intent is to focus on reducing overall project risk by working the high-risk/high-priority items early and then finishing up with those items that are lower-value or that we very capable of completing. For my development work, this would often be creating dialogs or things that were very simple or that I had a lot of experience doing. Those were stories that had an estimate with a high confidence level.

We didn’t use risk as the only factor in prioritizing the product backlog, but it was one of the inputs – along with any dependencies, technical debt, and features – that we used for prioritizing. But risk gave us an invaluable factor to consider when prioritizing or ranking the product backlog.

Closing Thoughts

When working on brand new technologies or with an unknown or untested tech stack, risk can be a vital tool in helping prioritize your product backlog. Make sure you’re using factors for your confidence and your business value that establishes the appropriate segmentation you need. You may want to make your must business value items have a factor of 100 to ensure they’re far-and-away the highest valued items in your backlog. Or you can do what we did and experiment with a variety of factors until we found one we liked.

Regardless, explore looking at risk in all of your projects to make sure you’re maximizing your opportunities to be successful. The riskier the item, the more likely it will fail to meet your timebox or scope goals and, in most cases, the longer it will take to complete. If at the end of your project your team is doing things they can do in their sleep, your chances of success are far greater.

Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)