Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Requirements  THE ART (OR SCIENCE?) OF PRIORITIZING REQUIREMENTS RIGHT
Previous Previous
Next Next
New Post 8/20/2018 7:20 AM
User is offline Srilatha
1 posts
No Ranking

  1. Get all involved in a room to discuss each participant’s reasons for priorities so that they are all heard.
  2. Don’t try to prioritize all requirements in one sitting.
  3. Try to get numerical priority (especially for high priority items) instead of general high, medium, low categories.
  4. Buy A Feature (Assign a value to each feature and give stakeholders a fixed amount of fake cash that they may use to “purchase” the features they most desire.)
  5. First In, First Out
  6. Prioritize by considering Cost of Delay
  7. Company Drivers/Department Drivers – Know the priority of each driver and based on that, prioritize the requirements.
  8. MoSCoW approach – must have, should have, could have, won’t have
  9. Determine if multiple requirements are addressing the same problem to reduce potential duplicates or conflicting requirements first.
  10. Agree on a Ranking/Rating System and define the rank values (High, Medium, Low; What do they mean?)
  11. Refer to the project objectives to identify high priority requirements. If a requirement does not help achieve an objective determine whether the requirement is out of scope or an objective was missed.
  12. Determine high priority requirements by asking “If you could only have x items in your solution which would you choose?”
  13. Priority Pyramid – Force the group to determine the most important feature or requirement for the top box. Next select the next 2 most important items for row 2.
    Continue expanding by one feature for each row until the pyramid is built. The top 2 or 3 rows would be the highest priority.
  14. Realize that priorities will change over time, even on short projects. Constantly revisit
    priorities to ensure validity
New Post 8/1/2019 2:31 AM
User is offline Stewart F
96 posts
7th Level Poster


Hi there,

I know this post is nearly a year old, but I read it and was rather perplexed by what it is actually trying to say. It seems to be a data dump for every way to prioritise requirements, as opposed to a step by step way to carry out the task.

For example, point 4 and 12 are one and the same, and the rest are variations on the same theme (i.e. they carry out the same task, but are just different ways of doing it). 

I would also say that 25 years experience as a Senior BA and now BA Manager tells me that step 1 is prone to failure. Depending on how large your project is, you could have 5 to 10 different senior personnel in the room. They will NOT want to be sat in a meeting room, probably for 3 to 4 hours, listening to everyone else's priorities. They have better things to do and will not spare the time. 

The biggest problem with prioritising requirements, and therefore the reason most of these may well fail, is that every stakeholder thinks their requirement is the most important. It certainly is for them and in the Dog Eat Dog world of business, they wont care about anyone else's priorities. 

By all means collate all the priorities but you are better off carrying out this task with your Senior Developer, Project Manager and Project Sponsor. The Dev will tell you a rough estimate to effort building it (assuming the project is technical - if it isn't then replace the Senior Dev with the person who is in charge of the area you are making the Change, for example the Operations Manager), the Project Manager and Project Sponsor who both have a handle on the political stance (what is crucial to the Business to get in first). Then look at impact - what is the Business Driver for the project, is it a new corporate Website? In which case, building the website would need to come AFTER you have agreed its contents. Equally though, could the developers start building the framework for the site? This is where your Dev comes in - he or she will be able to tell you the order the technical build requirements should come in and therefore their priority.

Most of the rest of the requirements priorities then fall into common sense and an agreed project scope. Is there a Phase One and Phase Two? In which case, can all the Phase Two stuff wait or does it NEED to be started early? If it doesn't - it waits. Common sense will tell you that you may well want a new Insurance Product, but if you haven't priced it up yet, what's the point of trying to sell it?

If you are left over with any other requirements that have similar priorities, then by all means get their owners together, but you don't need everyone in that room.  It wouldn't be the first time when I have told two Stakeholders that they aren't leaving the room until they have agreed a priority order between them. The best way is often the most honest way. Explain that you need to knw which needs to come first - let the two stakeholders argue this out between them and then get them to come back and tell you which is higher. Often, if you treat Stakeholders as adults, they will sort it out themselves. They just need to be guided every so often.

Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  THE ART (OR SCIENCE?) OF PRIORITIZING REQUIREMENTS RIGHT

Community Blog - Latest Posts

Nick Stowers
Nick Stowers
Introduction   When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity… other words, the focus is on the number of points clear...
0 Responses
Jason White
Jason White
New technology is in trend every day and striving to make its mark to be the best. It is not optional to stay exceptional, technology has made lives easy and uncluttered in so many ways that cannot be comprehended. With the latest technologies in the headlines every day, it is Artificial intelligence that is leading the race and being incorporated ...
0 Responses
The role of a business analyst is to manufacture a piece of art; the piece of art varies depending upon the methodology and techniques being used. Business analyst serves the project all through the beginning until the end and comes up with different pieces of art. It all depends on the case, the business analyst gets involved from the beginning of...
0 Responses

Latest Articles

Think you're a Business Analyst (BA) not a Salesperson? Think again...
Jun 28, 2020
When I began training to be a BA, I never dreamt that I would need to be a salesperson too, in fact, I'm glad I hadn't realized that as it may...
Copyright 2006-2020 by Modern Analyst Media LLC