The Prioritization Dilemma

Stakeholders frequently assume that if they mention a feature during discussions, it will be included in the final product. They might ask, "Why would I have brought it up if I didn’t need it?" Unfortunately, expressing a desire for a feature does not guarantee its implementation.

Effective prioritization evaluates how much each proposed requirement contributes to the project's business goals. This assessment helps teams decide which items in the product backlog can be postponed or removed. A prioritization process must take into account both the importance (how crucial is it?) and urgency (how quickly is it needed?) of each requirement.

Prioritization is inherently relative. It begins once the second requirement is identified and continues throughout development, even post-release. As new requirements or change requests arise, teams must assess them against the remaining backlog to determine when they can be incorporated. As business goals or market conditions change, a feature initially slated for a later phase may rise in priority.

The term requirement encompasses various requirements-related elements that teams manage, such as individual functional requirements, feature sets, use cases, user stories, or epics. Prioritization should only compare items of similar granularity.

While they are all classified as requirements, the reality is that some are more critical than others.

For example, an initial prioritization might be conducted on a set of use cases based on a preliminary understanding. As analysis deepens, teams can refine the prioritization of individual flows within those use cases to determine an effective implementation sequence. Some alternative flows may never be developed if other features are deemed more critical or urgent.

The Games Played with Prioritization

When asked to set priorities, stakeholders often instinctively respond, "I need all of these features. Just make it happen." It's challenging to convince individuals that certain desired features may not be essential, as they fear that labeling something as low priority might result in it being overlooked entirely. Indeed, this is the crux of prioritization—when resources are limited, it is imperative to deliver the most essential features first.

Even though they are all termed requirements, it’s evident that some hold greater significance than others. This becomes particularly clear during the often chaotic "rapid descoping phase" late in the development process, when lower-priority items are discarded to ensure timely delivery. By establishing priorities early, teams can make informed trade-off decisions rather than react in a crisis.

To help stakeholders evaluate the necessity of specific features, consider posing the following questions:

• What actions would be taken if that feature were unavailable?
• Is there an existing manual or automated workaround?
• Are there tasks that cannot be performed without that feature?
• What would be the cost or risk to the business if the feature were absent in the first release or permanently?

A common approach to prioritization involves categorizing requirements into three levels of priority. However, such systems are inherently subjective and require consensus on the meaning of each level. If left unchecked, stakeholders may classify 85% of requirements as high priority, 10% as medium, and only 5% as low, which complicates planning.

One client once shared that their priority levels were high, super high, and incredibly high. Unfortunately, altering terminology in such a manner does little to clarify priorities. To effectively prioritize requirements, teams should avoid engaging in these games and instead focus on how each proposed requirement aligns with their business objectives.

Factors Influencing Priority

Different stakeholders often have varying, sometimes conflicting, interests, making prioritization a potentially contentious issue. Everyone believes their needs are paramount, but the loudest voices should not automatically dictate priorities—a phenomenon known as "decibel prioritization." Certain stakeholders, like preferred user classes, may carry more influence when determining which backlog items to include in a specific development cycle.

Factors that can elevate a feature's implementation priority include:

• The value it delivers to the customer or business
• Its relevance to the project's or development cycle's objectives
• The identity of the requester
• Anticipated usage frequency
• The cost, time, and technical challenges involved in implementation
• Its time sensitivity, which encompasses urgency, compliance, contractual obligations, and the costs associated with delays
• Dependencies with other requirements that necessitate simultaneous or sequential implementation
• The risks related to implementing, delaying, or omitting the feature
• Its potential to mitigate risks in future developments or provide strategic value
• Its necessity for compliance with legal, regulatory, or safety standards

Another challenge in prioritization is quantifying what value entails. Assigning a precise dollar amount or numerical value to the benefits of each feature can be difficult. Thankfully, prioritization is a relative exercise, allowing teams to assess the comparative value of different features rather than needing absolute figures.

Some Effective Prioritization Techniques

Utilize the simplest prioritization method that suits your team. If a conversation yields consensus, that’s excellent. However, more structured approaches are often beneficial. The prioritization process typically involves four steps:

1. Identify the individuals responsible for making priority decisions.
2. Agree on the prioritization methods and the criteria for evaluating candidate requirements.
3. Assess the candidates according to those criteria.
4. Arrange the priorities within the requirement set and assign them to upcoming development phases.

Table 1 outlines several prioritization techniques. Some methods, like rank ordering, are suitable for smaller groups of items but become unwieldy with larger sets. Selecting an appropriate level of granularity is crucial to effectively apply these methods.

Analytical Prioritization Approaches

Most prioritization methods lack guidance on how to assess the relative significance of requirements. Exceptions include analytical methods such as relative weighting and criteria matrix. These approaches prompt participants to evaluate multiple dimensions that influence their priority decisions and then rank the candidate requirements based on these dimensions.

The calculated priorities enhance discussions about what functionalities to implement in initial development phases, making prioritization more objective and less susceptible to emotional influences or politics. Spreadsheets for both relative weighting and criteria matrix methods are available for download.

Relative Weighting

Figure 1 showcases a spreadsheet model designed to help estimate the relative priorities of various product features. This approach spreads estimated priorities along a continuum rather than restricting them to a few levels. The highest priority requirements provide the most significant product value (high benefit from inclusion, minimal penalty if omitted) at the lowest cost. Apply this method solely to negotiable features that are not in the top priority category.

Figure 1 demonstrates how to use this method, which is easier to implement than to articulate.

Step 1. Adjust the weighting factors in the top row to reflect your team’s decision-making framework. By default, all four factors are weighted equally. In the example, benefit is weighted twice as much as penalty and cost, while risk has half the weight of penalty and cost. Set a weight of zero to exclude a factor from consideration.

Step 2. List all items you wish to prioritize against one another, such as features. This technique is effective for several dozen items before it becomes cumbersome. If the list exceeds that, group related items to create a more manageable initial selection.

Step 3. Have customer representatives evaluate the relative benefit of each feature on a scale from 1 to 9, where 1 signifies minimal benefit and 9 indicates maximum benefit. These evaluations should reflect alignment with the product’s business needs.

Step 4. Have customers assess the relative penalty incurred if the feature is excluded, again using a scale from 1 to 9. For instance, failing to comply with regulatory requirements might incur significant penalties, as would omitting a feature present in a competitor’s product. The Total Value column reflects the weighted sum of the relative benefit and penalty for each feature, with features having low benefit and low penalty adding cost but little value.

Step 5. Developers should estimate the relative cost of implementing each feature, also on a scale from 1 to 9.

Step 6. Developers need to evaluate the relative technical or other risks associated with each feature, again using a scale from 1 to 9. The risk rating can be viewed as the likelihood that implementing the feature correctly will require multiple attempts.

Step 7. For each of the four factors—benefit, penalty, cost, and risk—the spreadsheet calculates the percentage of the total attributed to each feature included in the analysis. It then computes a priority number for each feature using the following formula:

Finally, sort the list of features in descending order of calculated priority to highlight the highest-priority items, as illustrated in Figure 1.

Criteria Matrix

Figure 2 illustrates a criteria matrix analysis for eight proposed features of a hypothetical product. This analysis considers six criteria; organizations should utilize criteria that are meaningful for their decision-making processes. Assign each criterion a relative importance weight in the top row, ensuring the weights total 100. The prioritization team rates each feature against each criterion on a scale from 0 to 10. The spreadsheet calculates each feature's score by summing the weighted ratings.

Negative factors, such as implementation costs and technical risks, are subtracted to determine the final score. Based on this analysis, features 1 and 7 should be prioritized for implementation, with scores of 4.3 and 3.6, respectively. Features 5 and 8 receive the lowest scores and can be postponed indefinitely.

Spreadsheets, complete with instructions and examples for both relative weighting and criteria techniques, are available for download.

Can We Reach Consensus?

Aligning stakeholder expectations regarding prioritization is crucial. Regardless of the selected method, it’s essential to clearly communicate the technique and rationale to key stakeholders, including executives. Otherwise, misunderstandings may arise when stakeholders don’t find all the functionalities they anticipated in the final product.

Deciding which requirements to tackle first and establishing the implementation sequence for others is among the most critical practices in requirements analysis. Continuously prioritizing items in your work backlog is fundamental to creating a roadmap that guides the process from requirements exploration to solution delivery.

This article is derived from Software Requirements Essentials by Karl Wiegers and Candase Hokanson, as well as Software Requirements, Third Edition (co-authored with Joy Beatty), which delve deeper into these prioritization techniques.