On “All about product management”, Derek Morrison describes a method of utilizing Agile techniques and Fibonacci numbers to determine a “Business Value.” Combining this with a technical value should provide a ratio that derives the strongest cost / benefit ratio.

http://allaboutproductmanagement.blogspot.com/2008/02/how-product-managers-can-estimate.html

However, I also agree with Jeff. Be careful not to devise a system where the members of the team voting on “Business Value” assume a democracy. Utilize the inputs from the team and your customers to prioritize the requirements inline with the vision and strategy of the particular product release and future road map. Don’t get lost in the statistics and end up in a situation where a product release is only characterized by small improvements in all areas. It is still important to develop compelling messaging about a particular release and make decisions to align product development efforts to the defined goals.

Is cost something not usually considered when assigning requirement priority?

At my company, we’re now working on a requirement prioritization table. I’m advocating a fairly simple approach: the prioritization of a requirement is directly proportional to the value of fulfilling the requirement, and the fulfillment value is equal to the benefit minus the cost.

All this is a fancy way of saying—how much will we get from meeting this requirement and how much must we spend to do it?

For “benefit,” I’m toying with a single value that represents positive financial impact, with two multipliers (things that can increase this “impact” value): the number of customers articulating the requirement and the degree to which the requirement is aligned with company goals/vision/etc.

On the cost side, I’ve pitched an “effort” value that also has a couple of multipliers: the perceived degree of difficulty in meeting the requirement and the degree of uncertainty regarding the effort estimate. That last multiplier is a bit weak and may be replaced by others, such as “comprehensibility of requirement” or “degree of specialization (within our engineering group) required to satisfy the requirement.”

Eager to hear what approaches others have found to be successful.

Use a good tool to do a logical ranking. there is a free tool for this at http://www.280group.com/shareware/freerequirementsroadmapmatrix.htm – it will help you set any criteria and weighting that you want.

Once I do this then I do a gut feel check (after letting it digest for a day or two). I find that I then get the right gut-level answer and can easily finalize and defend priorities.

Brian Lawley
Author, Expert Product Management
President & Founder, 280 Group
SVPMA President

The article is a bit long-winded, but it essentialy advocates combining multiple ranking schemes for your projects and assigning scores to each proposed feature (or enhancement or bug) for each scheme. You could, for example, assign scores on a 1-4 scale for things like “wow factor,” “revenue potential,” “request frequency,” or (in the case of bugs) things like “severity.” The scores you assign are ultimately arbitrary, but combining the schemes by adding up the points can help you sort through a long list of possibilities quickly. It can also provide a documented justification for your ultimate decisions.

I used a method like this for vendor evaluation, ranking each competing vendor on a scale of 1-10 for various things like financial viability, price, support, training, demo-able interface and the completeness of their coverage in several feature areas. Adding up all the scores quickly narrowed the field to two contenders and I was able to make a final choice on one or two of the variables I felt were key. A year later we are very happy with our choice of vendor.

Here’s the link:

http://www.productstrategynetwork.com/content/view/178/196/