Prioritizing requirements

[gescober]

I've occasionally done priority based on allowing stakeholders to "buy" requirements. I allocate them $1000 virtual dollars to spend on the requirements, and total the spending from all the stakeholders. That gives me a ranked order of requirements priorities, rather than the traditional 3-point scale.

How do you price the requirements? Based on development effort? risk?

[JGrapes]

I've occasionally done priority based on allowing stakeholders to "buy" requirements. I allocate them $1000 virtual dollars to spend on the requirements, and total the spending from all the stakeholders. That gives me a ranked order of requirements priorities, rather than the traditional 3-point scale.

I've done this and was surprised by the results. Priorities become really clear when the user is investing is development dollars.

[AlanAJ]

How do you price the requirements? Based on development effort? risk?

I think the point is that you DON'T price the requirements; it's a market. The "price" is set by the willingness of the "buyers" to pay, not the cost to produce. In theory, the more of this perceived value you can deliver for any given amount of money, the happier the "buyers" will be.

It's not true in practice, but that's a general flaw with prioritization! Allow your project to be influenced by relative priorities, by all means. But stakeholders are no more likely to give you the correct priorities than they are to give you the correct requirements... Like any other assumptions, you have to continually re-verify as your plans become more concrete.

[gescober]

But, if you don't set a "price" for the requirements, then you must set a budget for the users. Otherwise, they'd just say, "I'd pay a gazillion dollars for every requirement." It becomes meaningless unless you have a means of expressing the project constraints.

If you know how much a requirement or feature costs in terms of schedule, resources, or time; and you give the users a finite budget for schedule, resources, or time, then they can choose what they want given the project parameters.

I find that the trouble is getting the engineers to actually submit reliable estimates, or any estimates at all. It's easy when I'm building a house - I tell the contractor I want a second bathroom, and they tell me it'll cost $10,000 and take 3 months. I say, o.k., make it a half-bath instead of a full bath, and don't use tile; the contractor tells me, o.k., that'll be $7,000 and 2 months.

I guess this is a meta-issue. Prioritization is necessary because we're not sure what we'll get built because estimation is so poor in software development.

[MTalbot]

But, if you don't set a "price" for the requirements, then you must set a budget for the users. Otherwise, they'd just say, "I'd pay a gazillion dollars for every requirement." It becomes meaningless unless you have a means of expressing the project constraints.

Sorry, I wasn't clear. You give the users a fixed budget, say $100 virtual dollars, to spend on the requirements as they see fit.

[gescober]

But, don't you still need to set prices on the requirements? Otherwise, what stops a user from simply picking their top 100 requirements, and saying that they'll buy each one for a dollar?

[JGrapes]

But, don't you still need to set prices on the requirements? Otherwise, what stops a user from simply picking their top 100 requirements, and saying that they'll buy each one for a dollar?

I've been in discussions where I would have concluded two items were of equal importance to a user. Then said, if you had $100 to invest in features, how would you invest it? They surprised me by investing most of it in one feature. Users tend to understand that resources are limited and they are allocating their resources. So, they allocate their resources according to their relative priorities.

Oh, and one of the rules of the investment game is that you can't spend the same amount on two features, forcing the user to indicate relative importance.

[MTalbot]

But, don't you still need to set prices on the requirements? Otherwise, what stops a user from simply picking their top 100 requirements, and saying that they'll buy each one for a dollar?

This is actually just fine. It's a way of saying "every requirement is equally important to me". But when you do this exercise with a larger group of people, you start to have meaningful averages.

[MGoyal]

This is actually just fine. It's a way of saying "every requirement is equally important to me". But when you do this exercise with a larger group of people, you start to have meaningful averages.

I'm really intrigued by this this idea. what do you use to manage this effort? Excel and email or something more elaborate?

Thanks.

[Kevin Brennan]

When users refuse to prioritize it usually means one of two things:

1) they're concerned that the lower priorities will never get done if they let them go now;
2) they have an existing solution that does those things and don't want to settle for less.

In the first case, you really need to build up trust that the other things they need will get done, it's just that you can only do so much at once. Really, what they're looking for is a commitment that the project will eventually get around to doing what they need.

In the second case, you're probably not going to be able to get your solution deployed until you really have everything in place. In that case you either have to make the decision internally within the team or convince your users to support a pilot.

There's a good discussion of pricing schemes for prioritization in Alan Davis's Book Just Enough Requirements Management. Davis suggests that the biggest problem with this approach is that some stakeholders may try to game the results--for instance, if they know that other people will pay for most of the features they may save all their money for the one feature that only they want.