Suppose I offered you a chance to win $100. In a box, you have 90 balls to draw from. Of that number, 30 are red in color and the remaining 60 are either black or yellow. Kicker is I won’t tell you what that mix is. If I were to offer you two different wagers, which one would you most likely select:

One that pays if you select a red ball, or one that pays the same if you select a black ball.

Either gamble poses risk, and in fact may hold the same amount. There could be an equal mix of black and yellow balls, meaning that there are 30 of all three colors. Of course, there may be only 2 black balls and would be significantly less optimal to attempt that bet. 

The proposition was posed by Harvard economics student Daniel Ellsberg in the early 60s for his dissertation on decision theory. The accompanying study revealed that of the two choices, most people are more willing to take the gamble with determined amount of risk rather than the unknown — even if the odds were better. 

The study also had a similar gamble where you could choose either a bet that paid if you selected either a red or yellow ball, and a bet that paid if you selected a black or yellow ball. With there being a determined amount of black and yellow balls, it is less of a risk to take the second wager. Again you could have the same amount of red and yellow balls as black and yellow, but the number is not known.

Ellsburg’s dissertation was published in the Quarterly Journal of Economics in 1961, and the principle became known as the Ellsberg Paradox.

Moral is, risk is all around us. If we are going to decide the best route forward, we feel better making choices where we know the amount of risk involved.

When making things the Agile way, the Ellsberg Paradox is often presented. Stakeholders, team members and clients all want to be able to make decisions with a determined amount of risk. In a perfect world, we would have all backlog items properly assessed so the best decision about “what’s next” can be made. We all know that never happens, of course. Some items are fully defined, while others might have some technical questions or unfinished art.

How are we to make the right decision? Is it as simple as choosing the most defined first? Here a few ways that you can solve the paradox of unknown risk and keep everyone informed:

Understand that there’s no such thing as “unknown risk”. If strong communication exists between you and everyone else, there should be no risk that’s not known. Of course, I can’t solve for poor communication in this post, so let’s assume everyone’s talking. 

Once you communicate the risk, you should have everything you need. I would argue that most of the time, risk can be weighed but in a vacuum all risk is equal from the standpoint of just-in-time requirements. You might wish you could know more about a particular item, but knowing everything possible is all you can ask for. If what you know at that moment seems too high to pull the trigger, simply defer it until you can learn more.

Keep priority in perspective. The tough part is priority is often independent of risk. Clients may want a feature done right away because of external deadlines, yet it may have the most risk assigned. Kano analysis or weighted values might narrow down this some, but it still doesn’t solve the problem of what to do with risk.

Some teams will rate the risk just like the priority of a defect. Others may pad estimates because of the risk associated. To be fair, none of them are completely full-proof or faulty in design. The more you can build risk into your priority, the more outside stakeholders will feel a part of the decision making process.

Comfort level is associated with risk. Epics are going to have a fair amount of risk just because of the sheer size of the work. As you break them down into smaller pieces of work, the assumption is you will solve for some of it as it moves closer to the top of the backlog.

My experience of risk doesn’t have to do with challenging pieces of integration. Rather, it has to do with new APIs or third-party vendors. If the team has never worked with it before, there’s going to need to be some padding. Once a research spike or working session is complete, the work item could be moved up as more is known. Assess the team’s comfort level when a new item is first introduced and help groom the risk like all other requirements.

In the end, solving for risk is an exercise in transparency. If you understand, communicate and groom risk as a part of your regular activities, it is nearly impossible to make a poor decision when the time comes.

How are you solving for risk on your teams?