Buying features - prioritizing with poker chips
If you won the lottery and you saw 10 million dollars in your bank account tomorrow, what would you do? You would probably buy a lot of things… right? But actually you do not need everything you would buy, do you? Ok, you would have a lot of spare money, so there’s no problem.
But what if you had only a hundred dollars in your account? What would you buy? You would have to think about it more carefully and prioritize.
The product owner needs to define what is really important for him.
If you ask him what does he want for a 2 years project (10 million) he will say: “I want everything!”, but if you break down the project into small iterations (sprints) and ask him to prioritize what does he want for a small chunk of time, that’s when the important things come up.
A good way to show the product owner that he does not have 10 million available is making him buy features with a limited amount of money.
How does it work?
Before starting the poker chips session, we need a list of estimated user stories. We call it Master Story List (MSL), or Product Backlog. There are many ways of facilitating an estimation session, I like planning poker. But always remember: The team gives the estimates.
Basically you need to define how much a story point costs and give a certain amount of poker chips to the client according to the size of your iteration. And then ask him to buy what he wants for the next iteration.
It is interesting because from my experience as long as he has money, he buys everything, but then when he starts running out of chips, that’s when the real process takes place.
The output will be a list containing the most important user stories at that time.
I think it does not always works best for the COTS product that way. If the product manager does not know the every day pain pf the user (non resizeable dialogs, unneeded click actions, hard to read error messages, slow responsiveness) he tends to ignore the will of the users, and those modernization projects tend to get not enough prio. Same is true for technology legacy modernization or even for innovative new features where you dont see the immediate need. In those cases I would put aside some budget for exactly those stories and spent them in a different category.
I wrote this after the first time we tried it.
http://docs.google.com/Doc?id=ajk9hjp2k4px_10cfgw6h