Prioritizing requirements to maximize Business Performance

A product team always works under constraints of resources, time and quality; while there are always abundance of requirements which need to be implemented. We have also seen that a product need not have too many functions, since most of the customers use only about 10-20 % of the functionality, as indicated by many empirical studies. Many products (like iPod Shuffle) are a living testimony of this theory. In this article, we will look at the "Requirements Prioritization" process.

Applying the 80:20 rule here, we will start with an assumption that 80% of the customers need only about 20% key functions. A product manager getting the right mix will be able to maximize his / her business performance in terms of ROI. So requirements prioritization is extremely critical and needs a consistent strategy for a team.

In the (new) Agile world, this means constant reprioritization of all the backlog items in every Sprint Planning Meeting and choosing the most critical ones for the sprint. We present here some of the possibilities (and brief description of process), not in any specific order.

Here, it may also be worthwhile to consider the significance of Criticality and Priority attributes and how to use them for prioritization

• Criticality signifies the importance of requirement to the system.
• Priority signifies the urgency with which the requirement should be addressed. It usually implies the Manager's perception in a given context.
• In general, it is a good practice to prioritize the requirement by criticality followed by priority.
• However the Manager may take exceptions, based on the local context.

Some of the other aspects helpful in prioritization are

• Critical requirements with low developer confidence should be prioritized early.
• Non functional requirements can have exponential impact on cost, schedule, effort and quality. These should be considered early in the development lifecycle.
• If two requirements have the same priority and criticality, then the one with lower effort should be considered.

The requirements can be organized and prioritized using the following themes

1. Essential Business Objectives
   1. The key idea is that the product should be able to perform the most basic functions expected by the user.
   2. Create "Key Business Objectives" as a unique set in the Planned Requirements Table and define Requirements as children of these Objectives.
2. Common Functions offered by Competition
   1.  Users generally develop a perception of "Minimum Expectation" from a class of products in a marketplace.
   2. Anything falling short, is considered inadequate.
   3. So, this may be a good starting point to identify the bare minimum set of requirements.
3. Product Differentiators
   1. Once the bare minimum set of functions are implemented in the product; it has to achieve a unique position through differentiation.
   2. It may be a good idea to build another set of requirements, clearly identified as differentiators.
4. Frequent demands from the customers
   1.  Priority of certain requirements may be raised, based on the frequency of demands form the customers.
   2. It may be a chance to gain market-share by addressing the unmet needs of the market.

It may be pertinent to state that not all themes may fit in well with your context. Please feel free to pick and choose the ones which appeal to you.