This exercise was co-created as part of a collaboration day between myself and Paul Goddard
15-45 minutes (depending upon the size of the Product Backlog, number of stakeholders and amount of discussion)
A Product Backlog
Stakeholders in prioritisation
(Optional) Currency tokens such as monopoly money or poker chips
- Explain that this is an exercise to help collaboratively prioritise the Product Backlog
- Divide the currency tokens equally amongst the stakeholders or nominally allocate $1,000,000 per stakeholder.
- Give the stakeholders an allocated amount of time to “bid” on the items on the Product Backlog (10 minutes or so). Explain that they can spread their budget as thinly as they wish
- Once the time limit has elapsed, or everyone has spent their budget, collate the “bids” and reveal which Product Backlog items have received the highest amounts of money.
- For items that are completed, the money bid on those items is returned to the “central bank” at the end of the Sprint, and then re-allocated to the stakeholders
- Sometimes collaboration can happen accidentally with this technique i.e. one Product Backlog item comes out as priority #1 despite all stakeholders bidding more on something else
- Stakeholders will attempt to collaborate by pooling their money or offering to bid on each other’s items in alternate sprints
- The only way for stakeholders to get more money is by other stakeholders getting their Product Backlog items done
- No one stakeholder can dominate this process as, if their work gets done, they end up with less money to bid with next Sprint
- Decide the relative importance of the stakeholders and allocate an appropriate proportion of the currency amongst them i.e. $250,000 to stakeholder 1 and $500,000 to stakeholder 2
- Blind Bidding – Do not allow stakeholders to converse with each other while spending their budget, or let them see what the others have bid on.
- Open bidding – Allow, and even encourage, discussion, collaboration and negotiation amongst the stakeholders while bidding and make sure the current totals are visible at all times.
Certified Scrum Coach and CST in the UK and really interested in learning through play
3 thoughts on “Free Market Prioritisation”
You could add another variation:
Allow and encourage discussion and negotiation but don’t make the bids public. See how quickly this bogs down into mistrust, politics and protectionism.
Thanks for the comment Doc. I suppose I could take this as a compliment or an insinuation and although I would prefer it to be the former, given your association with the IG brand, I feel that you are looking for, and are arguably due, an explanation of why it isn’t the same.
When this idea was developed back in 2007/8 (and eventually published on the Scrum Alliance site in 2009) I hadn’t heard of innovation games but when I did come across the book I too noticed some similarities. I have since played “buy a feature” once and believe that there is at least two major differences in that, in “buy a feature”, all features have a price and that some features are priced so that no one customer can afford them on their own.
When Jason ran this on his project the costs of the features were not visible. In fact I doubt it had been worked out yet as we believed items should be valued before they were estimated and then prioritised once both figures were available.
Surely it is a compliment that something (a) so simple and (b) so sensible could be arrived at so similarly in two places.
All the best
This sounds an awful lot like “Buy a Feature” from Innovation Games / Luke Hohmann.
Comments are closed.