 As well as past the cards, another technique I've used with a lot of product owners is called priority markets or sometimes it's called free market prioritization and this is a technique that Jason Haynes and I developed and wrote about when we were both helping an investment bank adopt scrum. So this is much more of what we call a market-based approach. So each stakeholder is given some virtual money in the form of development dollars or Jeff dollars which they can use to bid on backlog items. It's a fair and democratic approach because all stakeholders get a voice in the prioritization process. It's also very open and transparent because everybody can see how each backlog item was prioritized. I also find it pretty efficient to administer and also scales well to large numbers of stakeholders and even if you've got a really long product backlog it still works quite well and this is how you do it. So the first thing you need to do is you need to set things up. So in our example here we're going to assume that the project already has a backlog of items. So here we're going to let's say we've got six backlog items and they've all got different costs of development associated with them. My first step as a product owner is to identify the different stakeholders who are going to be involved in setting the development priorities. Now I could if I wanted to assign a different importance weighting to each of those stakeholders based on how important they are to the product but to keep things simple in our example we're going to assume that our four stakeholders John, Paul, George and Ringo all have an equal weighting. I'll come back to how to handle stakeholders with unequal weightings a little bit later but let's keep it simple to start with. Now we've got our four stakeholders we're going to introduce the concept of development dollars. Now development dollars are a fake currency that we're going to use to allow the stakeholders to bid for and buy features or changes in the product. So we need to create a bank and that bank has some unallocated development dollars and we need to inject some development dollars into the system and then allocate them out to the stakeholders. Doesn't matter how many development dollars you inject into the system and you can mess around with it, tune it, adjust it as you get more practice at this but again for simplicity let's start with $40. The next step is to allow the stakeholders to bid their development dollars on the backlog item. So we're going to allocate those development dollars equally because they have equal weighting and then they can bid on whatever features they like. Now as you can see in our example here John has decided to spread his budget across features B, D and E but Paul is really keen on feature C. He's got a little bit of interest in D and E. George mostly favours D but also wants BC and E while Ringo really favours F. Got a little bit of interest in C and E. Once we've got those we can then determine the relative value of each item by calculating the total bid of development dollars allocated to it and then the developers can estimate the cost of each of those backlog items that has been bid on and with those two values we can work out a rough return on investment by dividing the total bid by the development cost. We order the backlog in return on investment and we've got priorities in this order F, D, B, C and E. Ordering by return on investment allows us to deliver items in terms of best bang for our buck. Now although change C or feature C has the largest amount bid on it it also has a large development cost so it's further down the priority list and F is at the top of the list even though it's only important to one single stakeholder but Ringo allocated 70% of his budget to it so it's obviously really critical to him. A has had no development dollars bid against it so it's at the bottom of the list and that's quite normal in a typical project there'll be a lot of items that have no dollars bid against them that doesn't mean they're actually unimportant it just means they're not right important right now and actually that's a real advantage of the method because the stakeholders can actually concentrate their attention on a smaller limited number of really important items on the product backlog. It's also important to bear in mind that like I said we're only estimating development costs on items that have dollars bid on them we don't have to waste our time estimating things that haven't been bid on. What do we do next? Well we take that prioritized backlog and the development team will start working on it for an iteration and in our example we're going to assume that the development team managed to get through the first two items in their next iteration so F and D have been successfully implemented. The next step is to reallocate the dollars that were bid on F and D so we can archive those items off the product backlog and those dollars that were bid on them need to be reallocated. In total there were 16 dollars that were spent on them. Now it's really important to know that 16 dollars goes back into the bank first of all it doesn't go back to the stakeholders who bid on them okay that's really important but F and D they can be taken out of the product backlog and we have another round of bidding. We need to reallocate that 16 dollars and we'll do that in the same way that we allocated the first 40 it goes out equally across the stakeholders. Ringo doesn't get back the seven dollars that he originally bid on F and John and George don't get their four dollars back and Paul doesn't get his one dollar back instead we take that 16 we divide it by the weighting which in our case is equal so they all get four dollars each back. All right really important come back to way in a minute. At the same time the original bids that were there for B, C, E and A are still there at least initially and once we've got that money back out to the stakeholders they have another round of bidding. Each stakeholder can reallocate the money that they'd spent before or they can just allocate their new unspent dollars they could add to the bids that they had before or they can just start again. If we've got something that doesn't have a development cost but now has a bid on it we would then do an estimate for that so that we can work out a new return on investment and we'd have a new prioritized order for the next iteration. Now by redistributing those development dollars and allowing the stakeholders to change their bids we're being very agile in response to any changes that might be happening in the stakeholders priorities. That's it basically that process just repeats itself iteration by iteration. Dollars spent on each iteration are reallocated and rebid. Now a couple of little nuances to this technique that you might want to be aware of. I did say about determining the stakeholder weightings that example we assumed simplicity and equal weighting for each stakeholder but in real life some stakeholders will typically be more important than others that could be because of the proportion of the user base they represent or the amount of money they're bringing into the product whatever it is but you can handle that in this technique by assigning different weightings and that will affect the number of development dollars that each stakeholder is allocated. So we could modify our previous example and use some different weightings in this case we would allocate our $40 very differently based on the weighting so in our example now John is the most important stakeholder George is the least important stakeholder and Paul and Ringo are about equal so their allocations then are based on their relative importance to the product they also reflect how much development effort will be devoted to each stakeholder so in our example John will receive 50% more development dollars than George. Now determining who the stakeholders are and what their weightings are can be a politically challenging exercise for a product owner and if a stakeholder group can't agree on a weighting amongst themselves it will be up to you as a product owner to make that decision. Whoever makes that decision though has got to be somebody sufficiently respected in the organization for it to have meaning. Now if you think about it weighting our stakeholders is pretty similar to a departmental budgeting process and one advantage of this approach is that the management team or the leadership team can make one single upfront decision about the relative priorities of the stakeholders for the product and that will avoid them having to micromanage the relative merits of individual backlog items and instead empowers that stakeholder group with control over the priorities based on a strategic decision. Priority markets I found a really useful technique to get priorities going amongst stakeholder groups it also has a number of different benefits to it as well. First of all it's scalable so even if you've got hundreds of backlog items priority markets allow stakeholders and the development team to focus only on the features or the changes that are immediately relevant so it avoids the trap that a lot of teams fall into of vigorously debating every item on a really long backlog if they don't have development dollars bid on them they stay in the backlog for later. It also scales well with the number of stakeholders so each stakeholder can bid independently of the others. One stakeholder can quantify the importance of their features or change requests by bidding on them and it avoids long discussions about why one backlog item might be more important than another. It's also fair because if a stakeholder hasn't had any of their backlog items implemented in recent iterations they will be steadily accumulating proportionately more dollars to spend in future iterations. I also mentioned it's transparent and transparency is important for fairness and for processes to be considered respected and useful so at any point in time each stakeholder will know exactly the priorities of the other stakeholders and they'll be able to see how development dollars have been spent so project priorities openly set transparently to everybody. You might want to be aware of a couple of psychological aspects to this technique because once you start monetizing the prioritization process you can see a few interesting behaviors emerging. You might see some bargaining where stakeholders get together and agree to bid on certain items together to give themselves a better chance of something mutually beneficial being successfully prioritized. You might see some trading with stakeholders selling their development dollars or giving them in this iteration in return for some more in another iteration. You might see tactical voting based on other people's bids, stakeholders might allocate more or fewer dollars to certain items. You might even see some government intervention. Now when the free market generates priorities that aren't in the strategic interests of the project, the organization, the product owner might step in and allocate additional dollars to a particular item. Now as with any free market, governmental intervention can have a number of negative consequences. It can increase inflation, reducing the relative value of other dollars. It can also disenfranchise the stakeholders because effectively they're having their priorities overridden. Now there will never be a perfect solution to the difficult process of prioritization. But past the cards and priority markets are just two pretty efficient and pretty effective ways of mitigating any people pleasing tendencies that might negatively influence your negotiations. They're both games aimed at giving multiple stakeholders a chance to participate directly in the prioritization process while also minimizing standoffs and bickering. And in the next section we're going to look at another common personality trait that can make your negotiations difficult, your perfectionism.