Image Source: Icons8 Team on Unsplash edited using Canva

Requirement Prioritization: A Future Proof Approach

Rohit Shinde
Jul 29 · 5 min read

Customer is the key, this is a clichéd statement we have been hearing for decades. However, in an interesting turn of events, I (a Business Management student turned Business Analyst) went a full circle around it. From overhearing to witnessing it be overused, I now stay in agreement with it.

As a Business Analyst, the customer is indeed the king and so are his/her requirements. For business requirements’ prioritization, focusing on client needs is what contributes to success stories.

But what happens when everything is important? There’s no room to cut, miss, or push aspects of a new project? That’s when requirement prioritization techniques enter to save the day.

Requirement prioritization techniques are the sequence of significance that helps Business Analysts to do their job better.

The absence of technology know-how and market competition compel clients to come up with new products, develop them at a speedy pace and ensure fast market rollouts. However, only products with the best features and sustainable technology guarantee longevity, customer delight, and a healthy ROI. To ensure products offer the same utility as planned is the role of an IT partner. And it all starts with knowing where to start, how to proceed, and when to finish.

What if there’s no prioritization technique

Many times, clients are unable to determine the importance or priority of the desired software product. Business Analysts can then interact, ask relevant questions, gather requirements, and leverage the collected data to establish the direction, duration, and multiple other aspects of a project.

  • The project purpose remains unclear
  • A huge possibility of miscommunication and misdirection
  • Not delivering value to the customer
  • Bad experiences, negative reviews, and sour relationships

The prioritization of project and its features provides the following guidance for multiple aspects of software development projects-

  • Which team should commence work and when
  • How to divide tasks within the team
  • A sequence of significance to catch and fix bugs
  • Which areas of the projects to focus on and why

Business analysts have multiple project prioritization techniques they swear by. Of course, the project urgency, length, importance decides the technique and every BA has his/her own method. Here are some methods that I have used and continue to do so-

  1. The Eisenhower Technique

Hands down, the Eisenhower prioritization technique is one of the best ones I have used to date. It helps BAs like me by simplifying the situation, organize thoughts and tasks to provide a solution. Within its matrix, there are four categories as follows-

Important and Urgent: These include the most important tasks which need to be done urgently. The tasks with a deadline approaching or the ones that cannot be delayed, generally fall in this category.

Urgent and Not Important: It constitutes of the tasks which are important, but not necessarily urgent. Generally, these tasks are in line with your long-term goals and contribute to your growth

Important and Not Urgent: This category refers to the tasks which are not important, but urgent. These tasks generally give you the deception of being important, while in reality, they don’t really contribute much towards your productivity.

Not Important and Not Urgent: Tasks that need to be eliminated (at least for now and can be taken up in the next sprints)

Image Source: Appfluence

Here’s how the Eisenhower prioritization technique helps software development-

It focuses on the needs of the clients and resources, skills, time, and priorities for the IT partner

It is simple to understand and effective to be applied

Helps cross-functional teams by providing a common goal and a mutually agreed upon schedule

2. The MoSCoW Method

Another technique I have used extensively and rely on blindly is MoSCoW. Also called the MoSCoW analysis or prioritization, it aims to mutually decide on the significance of features of functions in software applications. The letters M, S, C, and W stand for Must/Mandatory, SHOULD/high priority, COULD/Preferred but not necessary, and WOULD (Can be postponed and suggested for future execution).

Image Source: Visual Paradigm

When this sequence of significance is determined, it helps Business Analysts like me to orient software engineers and testers to prioritize their tasks and follow a mutually acceptable project schedule.

Here’s where the MoSCoW technique wins the brownie points-

  1. Simplified sequencing of significance: Assigning scores or percentages to every category of features in an application is something everyone is already familiar with. When putting things into a software development scenario, client teams are better able to understand and help determine prioritizations.
  2. With a clear distinction among the must, should, would, and could categories, BAs are able to better align significance and resources to the project.
  3. Based on the prioritizations, you can determine your team’s project performance, identify strengths, weaknesses, and opportunities. You can also set up a reward system to enhance productivity and run efficient agile sprints.

3. Numerical Assignment: This method is based on grouping requirements into different priority groups with each group representing something stakeholders can relate to. For example, requirements can be grouped into critical priority, moderate priority, and optional priority. Stakeholders may also classify requirements as compulsory, very important, rather important, not important, and does not matter in order to describe their importance.

Rank ordering, action priority matrix, scoring, etc. are some of the other techniques used by IT organizations across the globe. The choice is yours; you can choose the best one for me or the best one for you. You can combine more than one methodology for your project as well. It all comes down to the time, money, resources, skills, and effort involved in the project.

In summary

As software development projects continue to involve multiple stakeholders of diverse backgrounds and functions, it is important to consider them and commence with projects. If the code quality is important to an engineer, automation tool for a tester, fixed schedules for a scrum master, or the look and feel of the application for a UI/UX designer, project prioritization methodology will consider it all and deliver the best outcome.

Here’s the overview of using prioritization techniques from a Business Analyst’s POV-

Helps understand the client better: Project purpose, stakeholders involved, urgency, budget

Orients software development teams: Prioritize tasks, clear purpose, less miscommunication, more granularity

High-quality product outcome: Helps PMs organize skills and resources well, arrange sprints, reduce product backlogs


A Bespoke Engineering Studio