I define prioritization as the process of assigning priorities to a set of items. In requirements engineering, I apply it to requirements. First, I state clear goals. Then, I sort requirements so that I can decide what to implement first. For example, I ask users two simple questions. First, I ask: How satisfied would you be if the requirement were fulfilled? Second, I ask: How dissatisfied would you be if the requirement were not fulfilled? These two questions help me classify requirements with the Kano approach. Moreover, they help me see both value and pain.
I choose a prioritization technique based on context. For routine work, I often use ad-hoc techniques. For critical or security-sensitive work, I use analytical techniques. Ad-hoc methods work fast. However, they are subjective. Therefore, I document opinions and assumptions. In contrast, analytical methods give more traceable results. For example, I use the prioritization matrix according to Wiegers. I also use the Analytical Hierarchy Process (AHP). Nevertheless, I limit analytical methods to smaller lists. Specifically, I prefer analytical methods for up to 30 requirements. Otherwise, the effort becomes too high.
I use several ad-hoc techniques in practice. For instance, I use requirements triage, ranking, the Top-Ten technique, and planning poker. In addition, I use the 100-dollar technique and two-criteria classification. Also, I apply Kano classification when I want to balance satisfaction and dissatisfaction. Furthermore, I use single-criteria classification for quick filtering. Consequently, these methods let me presort large requirement lists. Then, I apply more precise techniques to the optional or unclear requirements.
I follow a clear prioritization process. First, I select the prioritization technique. Next, I define who will evaluate each criterion. Then, I adapt the attribute schema if necessary. For example, I add attributes that capture priority, cost, risk, and relative benefit. Afterwards, I perform the prioritization as planned. I document all evaluations. In addition, I record justifications and assumptions. Finally, I check the requirements regularly and reprioritize when needed. I do this always before an important decision.
I weigh costs, benefits, and risks explicitly. For example, in Wiegers’ matrix, I compare relative advantage and relative disadvantage with relative costs and relative risk. Similarly, with AHP, I compare pairs of requirements to derive a ranked list. Hence, I achieve more neutral and measurable priorities. Nonetheless, analytical methods take more time. Therefore, I reserve them for critical decisions or when traceability matters.
I involve stakeholders throughout the process. First, I identify stakeholders and their goals. Then, I assign responsibilities for evaluation. Also, I ensure domain experts rate specific criteria. Thus, I increase the quality of the result. Moreover, I maintain a transparent record. As a result, other team members can review and reproduce the prioritization decisions.
I monitor priorities over time. Things change, and priorities change too. Therefore, I schedule regular reviews. Also, I update priorities before releases and major planning sessions. In summary, I balance speed and rigor. Consequently, I achieve priorities that support good planning, risk control, and stakeholder satisfaction.