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.

Last week, I attended the first Swiss Lean/Agile/Scrum conference. As usual, the Swiss take a long time to catch up with new ideas and technology, but when there’s money to be had, they’re right up at the front of the line. Anyway, Ken Schwaber gave a very interesting presentation on the concept of “Done”. He showed the canonical burndown chart, and then took the individual vectors apart.

Seeing the variables separated like that got me to thinking, and I had the chance to run my thoughts past Karl Scotland and Keith Braithwaite, both of whom went out for a beer with me afterwards.

Back in the early days of XP, we defined a set of project variables:

The rule went, “Time, Resources, Quality, Scope – choose three”. Whichever three you chosse, the fourth variable would be a function of the other three. Which three were actually chosen was the customer’s decision. Some customers (and managers) don’t understand this rule, and try to grab control of all 4 variables. By doing that, the first variable that’s dropped is quality, followed by time.

So, how do these sets of variables map to each other? The first two are easy:

• time = time
• backlog = scope

The other 2 are a bit more difficult:

• V = f(R)

Velocity (burndown rate) is a function of the available resources. Regardless of what you have to do, having more resources will normally allow you to go faster. This function is non-simple and non-linear, unfortunately: as Fred Brooks rightly says, “adding manpower to a late software project makes it later”, but the simple case is a more or less linear function.

Quality is even more complicated:

• q = ∂V/∂t

As Dan Rawsthorne says, “Quality is the first derivative of the burndown”. The quality of a product is directly related to the development velocity/burndown rate.

So, so much for that thought. Keith spun the thought even further, proposing in his recent blog post that you can increase velocity by increasing quality. I agree with him, and I recommend you read the post.

At the end of my Scrum courses, I do a final exercise and let the attendees prepare a 5-minute presentation on Scrum. Depending on the people and circumstances, this presentation may be targeted at management, marketing, customers, developers etc. At a recent course, someone asked me how I would present Scrum as an elevator story to management, and I remembered something I used when starting my business in 2001:

Scrum is not a win-win proposition, but a triple win-win-win proposition. It meets the needs of all 3 parties involved in the process: customers, management, and developers.

• Customers  win by getting the product they actually want and need.
• Management wins by having a real-time tracking and controlling of time and budget.
• And last but not least, developers win by having the freedom and responsibility to build world-class products.

That’s my story in a nutshell…