Kicking Risk Down the Road Jeopardizes Success

It’s 1230 and you have a report to write, an international flight to catch at 1600 and at least an hours drive to get to the airport. What do you do first?

Most of us assess the risk and realize that there are many more ways we can be late for the flight than on time. The journey to the airport has the most uncertainty so we complete this first. We can then write the report relaxed at the gate. We call this risk management approach nothing more than common sense.

Common Sense Uncommonly Applied
We have the same opportunity to use risk management in our planning process when we order our backlog. But most of us don’t. Why?

Most product owners now prioritize the backlog order based on short term value rather than taking risk in to account. One of the key risks they reasons is the loud legacy of too many late projects due to engineering choosing to implement the product in bleeding edge technology and this not working out so well.

In this move to focus on shorter term value in our products we’re now failing to acknowledge that we can’t just mitigate the risks of technical novelty by scoping it out. Technical novelty has to happen for reasons of competitive advantage or deprecated technologies. So we need to bring that common sense back in to our planning process.

One of the ways to address this is to bring technical risk into the prioritization process.

A Way of Using Risk to Prioritize the Backlog
So how can we think about this from a backlog priority perspective?

One way is to create a matrix of technical risks to be addressed on the y axis and user stories on the x axis. See below:-

The user stories are true user stories, if they’re delivered a user can do something valuable in their process. I put a cross at the intersection of a risk and user story where it shows that if we build and appropriately test that user story it demonstrates that we’ve mitigated the risk. I then look at the user stories with most crosses, balanced with the least effort and the largest value and prioritize those to the top of the backlog. In the above example I’d want to build and test user story 3 as early possible.

This approach is an aid not the answer to your backlog prioritization. We still have to make the trade offs in terms of prioritization between building and maintaining market credibility and building a sustainable solution. We reserve the right to make short term trade offs by building “sparkler” features to keep market interest, preferably those with high value and low technical risk. We may even decide to build “sparkler” features early that have high technical risk but either cut the capability back to manage the risk or accept the risk; then rework when we have time. This way we go in clearly understanding that we’re taking on debt in terms of rework and/or risk in terms of market credibility to realise the additional value of reduced time to market.

Conclusion
Most organisations I’ve come across have little recognition of how to actively manage technical risk.

Ordering your backlog by taking into account those user stories that if built would address most technical risk is one way to increase schedule predictability

It can be argued that the value I describe above is a positive way of stating market risk and that I could have one combined list of technical and market risks. That leads on to the next post…