The Community Blog for Business Analysts

Praveen Udupa
Praveen Udupa

Step into Right Priority

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

  1. 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.
  2. Tell 'em how it's done: Right at the beginning of your project, when you create (or tailor) your Requirements Management Plansocialize 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.


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. 

This entry was published on Jun 08, 2016 / Praveen Udupa. Posted in Requirements Analysis (BABOK KA) . Bookmark the Permalink or E-mail it to a friend.
Like this article:
  27 members liked this article

Related Articles


Helen posted on Wednesday, July 20, 2016 2:04 PM
Thanks for this article, it is really useful and a common problem. It's so difficult to persuade stakeholders that not everything should be a must. Unfortunately they fear they won't get it otherwise so see it as a bargaining tool. On the flip side I've encountered IT stakeholders who automatically dismiss all requirements that are not a must so this doesn't help. Another technique I found useful once was to get the stakeholders to put the requirements in strict sequential priority order. This then helped agree how to categorise the requirements afterwards into the MOSOW format. This probably wouldn't work though unless have a good and trusting relationship with the stakeholders doing the prioritisation as they were a bit nervous .
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC