Requirement prioritization helps you to decide which product requirements to build first. By prioritizing, if you cannot complete the entire list, you will at least be able to complete the most important features.
Your product roadmap defines a theme or date for a product release. When you accumulate all of your product requirements for the release, invariably there will be too many to fit into one release. You will have to decide whether you will be working with a set release date or not (for more information, see the article, The product release and the project triangle: Scope, cost and schedule). If you decide on a set release date, then you must decide which requirements to include.
The following steps will help you create and order your list of product requirements based on the overall priorities of your company.
When prioritizing product requirements, identify your company’s current primary focus from among the ones listed below. This primary focus is usually driven by your stage on the technology adoption curve (for more information, see Prioritizing your product roadmap).
Your company may be focused on more than one of these at a single time. However, there will be one that drives many of your decisions right now, which makes it the most important. Rank the list above according to your company’s current priority; you may choose to add additional focus areas.
Using the list above, review each of your requirements and decide which area of focus it supports; this will categorize each requirement.
Note: You may notice that some requirements will belong to more than one category. This will make the requirement even more important to your business.
Once you have categorized all your requirements, the next step is to determine how well they support this category (area of focus). The more the requirement supports the category, the more important it is. This evaluation is best done using a ranking of 1 to 10 (lowest to highest). The range of the ranking may vary for your business, but keep it consistent across all categories.
How you determine the requirement’s importance will depend on the category:
Note: This process is not an exact science, but it ensures that you apply a consistent methodology across each requirement.
Once you have rankings and categories for each requirement, you can create a weighted ranking for each requirement. Weighted rankings result in numbers that are calculated to show the absolute importance of the requirement as compared to others. It does not matter that the requirements might all be very different; this method allows them all to be compared equivalently (apples to apples).
Imagine that the following two requirements must be ranked:
|Requirement name||Category||Category weight||Ranking||Weighted ranking|
According to this weighted ranking, although they are very different requirements, the“Customer import” feature ranked much higher than the“Password reminder” feature.
Once you have ranked all items, you can see how important they are relative to each other. Rely on your experience to review the list, to determine which features seem to be out of order, to identify flaws in weighting and to understand why an item is important. The system of weighted ranking is not perfect, but it provides a methodology to evaluate each requirement objectively. It can also provide a point of discussion.
As you evolve your product over time, your weightings will change. Be sure to regularly revisit your primary area of focus to examine if your priorities have changed. Once you understand the business priorities of your requirements, the next process is to assess the cost to build the solution. This way you decide what to include in your release.
Note: For more information on product requirements, refer to the other five articles in this series:
Davis, S. (2008). Requirement Ranking– No, No, No to High, Medium or Low. Retrieved August 9, 2010, from http://www.requirements.net/2008/04/25/requirement-ranking-no-no-no-to-high-medium-or-low/
Murphy, J. (2005). Getting Your Priorities Straight: A Twisted Path. Retrieved August 9, 2010, from http://www.pragmaticmarketing.com/publications/topics/05/0501jm2