### Thoughts on priority poker

#### by admin

Many years ago, I took part in one of the first Certified Scrum Product Owner courses ever held by Ken Schwaber and Mike Cohn. One of my favourite exercises from that course, and one I’ve often used since, was priority poker. Priority poker is a method for assigning relative priority, or weight, to items, and is based on methods recommended in multi-attribute utility analysis literature[1]. In this exercise, you spread your user story cards out on a table, and allocate a number of poker chips to each story in order of their importance. Priority poker is a great learning tool. It’s easy to learn, it’s tactile, and it’s fun. For me, the most important learning experience of this exercise is the “aha” effect that comes from realising that the number of resources is finite, and that prioritising a particular story higher comes at the cost of prioritising another story lower.

Figure 1: Priority poker

A question popped up recently in one of my product owner courses which made me re-think a few premises about priority poker. Two groups came up with a different number of stories for an exercise we were doing, but I gave them both the same number of poker chips. Looking at the results of the group’s prioritisation exercise, I realised that there must be some connection between the number of stories and the number of chips. What would be the optimum relationship/proportion between chips and possible stories to ensure the best possible prioritisation? With too few chips, there’s not enough flexibility in choosing. With too many chips, things can become equally important, and one loses the nuances of such an exercise [2]. Is there a mathematical formula to calculate this? Empirical data? Rules of thumb?

I’m lucky to have many friends who are a lot smarter than I am, and who don’t mind me asking them questions like these. In this case, my victim was my friend Dr. Natasha Zharanova, who works in the finance department at eBay in Amsterdam, and who did her PhD in economics at Princeton. Natasha once attended a product owner training I did while working at eBay where we did priority poker, and she mentioned to me that she had done her master’s research on a similar topic, cumulative voting. Her answers to my questions caused me a thoughtful and sleepless night, tossing and turning in bed thinking about this question, until I finally gave up and started hacking Smalltalk at 3:30 AM to run some simulations.

Natasha pointed out that one of the goals of cumulative voting is to ensure adequate minority representation. Indeed, when we did the exercise together, we had given various stakeholders a few chips, and their strategic placement of chips influenced the final prioritisation in interesting and unexpected ways. (Note: you probably know cumulative voting as “dot voting”, where each member of a working group gets 3 dots to place on their e.g. favourite topics to be discussed).

Some points which Natasha pointed out to me:

– the total number of votes allotted to a voter is equal to the number of winning candidates.

– This works when all voters are seen as equal. When it comes to shareholders, usually the number of votes one gets is also proportional to his/her number of shares (I.e., a shareholder with 10\% of shares gets 9 times less than one with 90\% of shares), but the total sum is still related to the number of winning candidates.

– Of course, in most examples where this is used (I.e., board of directors elections), the number of open positions is fixed. In my example, though, the number of stories selected is not known in advance; but perhaps this is where another assumption / rule of thumb could be introduced? Something along the lines of “there is no way that more than 5 stories can be top priority simultaneously”? Then everybody gets 5 chips…

With a product owner (in a strict sense), the number of voters is 1. This simplifies things a bit, as it forces the focus onto the relationship between votes (chips) and options (user stories). Natasha’s question of “how many projects can be top priority simultaneously?” got me thinking, and I ended up reversing it, asking “how many projects or stories can we afford to ignore?”

I think the optimum number of votes would be the minimum number that ensures that each option can receive a unique, non-zero number of votes. For 1 item, it would be 1 chip. For 2 items, it would be 2+1, or 3, chips, for 3 items 3+2+1, or 6 chips, etc. The number of votes would be a number in the sequence 1, 3, 6, 10, 15, 21, 28 … or essentially, for n items:

or simply

This would be the smallest number of chips that would allow all options to be represented, while still forcing an increase in value of one option at the cost of another.

Looking at the first formula, the last (n – 1) becomes interesting. This is our lower bound, normally 1, but what it represents is the number of options we can afford to ignore, right? If we substitute this number with a higher bound, thus saying that we can afford to ignore more items, then the number of votes necessary to ensure prioritisation decreases. For me, this lower bound would be the number of stories that we can allow to have 0 chips.

I couldn’t get that number sequence 1, 3, 6, 10, 15, 21, 28 … out of my head. I was sure I’d seen it somewhere before, but couldn’t remember the name. Factorial? Sort of, but adding, not multiplying. Fibonacci? Sort of, but summing up all previous numbers, not just the last two.

In cases like these, I normally call on my math wizards, Tatiana Pastukhova and Wiggert Loonstra. They both gave me the answer: triangular numbers. Think billiard balls here.

Figure 2: Triangle numbers

A triangular number is the number of balls in an equilateral triangle completely filled with balls. Looking at the Wikipedia page on triangular numbers, I found the most efficient way to calculate them:

So, to figure out the number of chips you need for prioritising your backlog using priority poker, first figure out how many stories you can afford to do without (this is a good reality check in any case). Then let

and the number of chips needed will be

Simple, right?

Notes:

1. See Emil J. Posavac and Raymond G. Carey, Program Evaluation: Methods and Case Studies, Prentice-Hall, 1989; W. Edwards and J.R. Newman, “Multiattribute Evaluation”, in H.R. Arkes and K.R. Hammond (eds.), Judgment and Decision Making, Cambridge University Press, Cambridge, England, 1986, 13-37; and C. Kirkwood, Strategic Decision Making: Multiobjective Decision Analysis with Spreadsheets, Duxbury Press, 1997, 53-61.

2. See Barry Schwartz, The Paradox of Choice, Harper Collins, 2005.

[…] This post was mentioned on Twitter by The Agile Developer, Hannu Kokko. Hannu Kokko said: RT @agiledeveloper: Complex and Agile – Joseph Pelrine: Thoughts on priority poker http://bit.ly/eD67dg #agile […]