Requirement Prioritization Tips
Here are 4 tips to help you prioritize requirements better.
1. Understand the problem you are trying to solve right now.
Get a clear understanding of the main problem and preliminary problem you are trying to solve. The application is aimed at solving a problem for the user. I will call this the main problem. But right now, your goal could be to build an MVP so that you can get user feedback or attract investors, this I will call the preliminary problem.
Understanding both the main and preliminary problems is crucial as it helps you understand which requirements are most important.
2. Use Prioritization
Define prioritization levels. Each requirement (or user story) needs to have a priority assigned to it. For example,
a) High- requirements that are impactful to the immediate problem. Can’t do without it.
b) Medium- good things, but not very impactful to the immediate problem.
c) Low- nice to haves
3. Use a Ranking System.
Every requirement needs to be ranked according to importance. Here, you are saying requirement #1 is more important than #2. And requirement #2 is more important than #3 and so on. Hence there’s no ambiguity about which is more important.
This would aid the development team to understand what is most important for them to focus their attention on. Hence, they would work on 1, 2, and 3 in this sprint. And 4, 5 and 6 in the next sprint.
4. Understand Timelines & Cost
By now you would know that the high priority items are the most important. They are essential to solving the problem. The medium priority items are really good stuff as well. But the team needs to also understand where to draw the line between high and medium priority items. Should we accommodate any medium priority requirements or not? In this situation it’s time to make a decision; if there are any medium priority requirements that are easy to deliver, and do not take more than 1–2 hours maximum, we would do it. If it’s more than 2 hours, we will skip it.
All it takes is a little bit of analysis, a little bit of collaboration with your team to give a gut check on each of those requirements and say, “How long would this take?” or “How much would this cost?”
You can find your stakeholder’s priorities tend to shift a little bit when these questions are asked. Sometimes a requirement you thought was important, like priority 1, you may be like, “Oh, that’s two weeks of work? It’s not priority 1, it’s more like a priority 2, or even a 3!”