The previous two posts in the Requirements Prioritization series, we discussed the honest difficulty that stakeholders face when asked to simply prioritize requirements, and how to overcome this obstacle by using prioritization parameters. If you have not read these posts, I recommend you read them first here and here.
In this post, let's discuss some of the requirements prioritization best practices. I will attempt to organize these best practices based on when these will be applied during requirements engineering journey. So here goes...
Requirements Planning Stage
- Determine the Stakeholders: Discuss with the Sponsor and other key stakeholders to determine a cohesive set of stakeholders who will participate in the prioritization exercise. Remember that it is totally possible (and acceptable) that more stakeholders might be added to this set. This information will straight away be updated to your RACI matrix.
- Tell 'em how it's done: Right at the beginning of your project, when you create (or tailor) your Requirements Management Plan, socialize your prioritization plan (among others) with the stakeholders. Help them clearly ‘get’: the Prioritization Process (we will discuss the process in detail later in this post), the Prioritization Parameters (i.e. the Glasses), their weights, the Rating Scale (all of which we will determine in collaboration with the stakeholders) and the Frequency of prioritization. You may use a spreadsheet (download) to facilitate this discussion and the prioritization exercise.
- Prioritization Parameters: Present your recommendations to the stakeholders on the Prioritization Parameters that makes sense for your project. Explain to them what each parameter means, and more importantly, why you think they are relevant to your project. Ensure you achieve consensus among stakeholders and have their approval.
- Parameter Weights: Not every prioritization parameter will matter equally to the stakeholders. For instance, most stakeholders will want Business Value to matter more than, say, Implementation Difficulty; thus Business Value is assigned more weight than Implementation Difficulty. There is no limit to the number of parameters, although more the parameters, higher the time required for prioritization. Optimally, 5 or 6 is a good number.
- Rating Scale: MoSCoW (Must, Should, Could and Wont) is a popular rating scale. You could chose a HML (High, Medium, Low) or a vH-HML-vL (v stands for very). I personally would use a numerical scale, say a 1-5 or a 1-10 scale. This provides more flexibility in assigning minor variations in priority. Even if you use a non-numerical scale, like MoSCoW, you must assign a numerical value to M, S, C and W. This is to ensure you can calculate the weighted average and derive the overall Priority (see spreadsheet)
Remember, while walking the stakeholders through the above, your tone and tenor of presentation is to ‘collaborate’, and not ‘dictate’. You must be open to customize any aspect of prioritization – stakeholders involved, prioritization process, parameters, weights, rating scale, and frequency
Requirements Prioritization Process
Step 1: Schedule a workshop inviting only the relevant stakeholders. Share with them the prioritization spreadsheet in advance. If you are using a requirements management tool, which has built in prioritization capability, provide access to this tool to the stakeholders. This helps the stakeholders prepare for this workshop (although you should not expect all stakeholders to be prepared. In they are, it is a bonus!)
Step 2: At the beginning of the workshop, ensure that all stakeholders are aware of the prioritization plan (described to them during the requirements planning stage). If not, repeat the plan and ensure all stakeholders are on the same page.
Step 3: Focus the stakeholders on the requirements being prioritized. Typically, prioritization workshop follows requirements sign-off workshop. You would therefore assume that the stakeholders already have an uniform understanding of the requirements. However, at this point, it is a best practice to ensure that there are uniformly understood by all stakeholders.
Step 4: Direct the stakeholders to the first prioritization parameter. Have them go through every requirement and provide their individual rating based on the first prioritization parameter.
Step 5: Once everyone completes Step 4, consolidate the ratings from all stakeholders and derive the average rating for each requirement. Request the stakeholders to review the average rating, and compare it against their own individual rating. If there is too much deviation, request them to surface their concerns. Facilitate an open and free discussion, and forge consensus among all stakeholders.
Step 6: Move on to the next parameter, and repeat Steps 4 and 5 until all the parameters are covered.
Step 7: Derive the overall priority. Ensure that all stakeholders approve the priority.
That’s it…you are done. You may repeat the prioritization exercise as many times as you wish during the project. In fact, projects following Agile methodology require that the user needs are continuously prioritized.
Conclusion
In this three-part series on requirements prioritization, we discussed why stakeholders find it difficult to prioritize requirements, what you can do as a Business Analyst to help them and how exactly you would go about helping them.
Let me know your views and feedback.