One of the recurring issues of using Scrum, or any agile process, is how to determine the priority of stories/tasks in the backlog. This is usually more difficult than determining effort.
The Product Owner usually uses their best guess, based upon their experience and close discussions with client, to do so. However, I have worked with clients that often have internally conflicting business needs that are not simple for Product Owners to reconcile.
While on a chat with Thomas Johnson talking about my current woes looking for new employment, we talked about this particular issue and our discussion inspired us to come up with an interesting concept that he called Tender Driven Development, and I called Cash Driven Development, that essentially distributes the prioritisation process across client stakeholders to handle conflicting business needs.
Essentially, the client gets an overall budget for the project, and then have to allocate their project points to the stories/tasks as they see fit. This is really an extension of the famous Story Points model, but from the client prioritisation side, and not using Fibonacci.
Let’s say that the client has two competing business owners, they each get 500 project points to allocate across the 100 stories/tasks, which they then do. The Product Owner then chooses to implement the ones with the highest aggregated points first. [Taking into account any interdependencies, of course]
This is akin to a person waving a 50 Euro note in a bar standing next to someone waving a 20 Euro note. The 50 Euro note guy normally gets served first. [Frustrating, but that’s capitalism]
Now, I have been in a situation where we actually tried similar to this with a client during the initial specification phase of a large project, but there was no budget and no internal conflicts to resolve. We used the same Fibonacci approach as used in effort estimation. This lead to the client considering everything a 1, and virtually nothing as a 3 or 5. [Low values had higher priority in this approach]
By giving the client a fixed budget of project points and, if there are competing business needs, splitting this up across the stakeholders, we can get a clearer understanding of the actual priorities of the client, without the Product Owner getting bogged down and confused with the clients internal politics. [Any features that end up having 0 points would be removed from the backlog.]
I am aware of similar techniques, like Microsoft’s Buy a Feature approach, but they put a “price“, usually related to effort, on each story/task. To me this is going a bit far, and not very agile, as we need to have the developers estimate their effort before the client prioritises the backlog. Whereas, in Scrum and most agile process, the effort estimation occurs in the sprint planning stage after prioritisation.
The Cash Driven Approach [or Tender Driven] is really just a simple tool to assist Product Owners gain an insight into the clients own prioritisation of features which they can then use to assist them in the prioritisation of the stories/tasks for each sprint. Unlike the client the Product Owner has to understand the impact of stories/tasks that are not directly related to features [like; knowledge acquisition, technical debt, and bug fixing] that would not be considered a high priority to a client stakeholder.