Requirements prioritization
To bring to a client most of the value with the help of a selected solution, the team should identify most critical requirements for the project success, their urgency, and the appropriate delivery order. Requirements prioritization is used to serve this goal. It is a process of decision-making to determine the relative importance of requirements based on their relative value, risk, the difficulty of implementation, and other criteria. As a result of this activity, the requirements are listed in their implementation order.
Different criteria are used as the basis for prioritization. The examples are listed below but not limited to:
Business value. Requirements are prioritized according to their relative value to the final solution based on cost-benefit analysis. The most valuable requirements are selected for development first. The approach is recommended when delivery is done incrementally, or the task is to enhance an existing solution that already meets baseline requirements.
Likelihood of success. The approach selects the requirements that should produce quick and certain success. The approach is valuable when a project should demonstrate fast progress to gain stakeholders' support.
Implementation difficulty. The approach is often selected during POC and takes into scope requirements of lower and medium complexity to advance with the solution quickly and get familiar with more complex things while working on a reduced scope of features.
Stakeholder agreement. This is a consensus decision made by stakeholders on the delivery order of requirements. Usually, it is not a stand-alone approach but a combination with other approaches.
Policy compliance. Requirements to meet regulatory or policy demands should be taken first, which can take advantage over any other interests or priorities.
Relationship to other requirements. Requirements that support other high-priority requirements or serve as prerequisites for them are also prioritized.
MoSCoW analysis
The MoSCoW analysis is a prioritization technique that divides requirements into four categories: Must, Should, Could, and Won't. Category descriptions are as follows:
Must. A requirement that must be fulfilled for the solution to be considered a success.
Should. A high-priority item that should be included in the solution if possible. Usually, it is a critical requirement but can be satisfied in other ways in case of any constraints.
Could. A desirable but not necessary requirement, selected for development only when time and resources allow.
Won't. A requirement that stakeholders agreed not to implement in a particular release depending on business needs but which can be included in future releases.
Timeboxing and budgeting
The technique prioritizes the requirements based on the allocation of a fixed resource:
Timeboxing prioritizes requirements based on the amount of work that the project team can deliver in a set period of time.
Budgeting is applied when the project team is allocated a fixed amount of money. To determine requirements to be included, use the following approaches:
All in. Assign duration or cost to all the requirements, include them all in the scope, and start removing requirements from the scope to meet the calendar dates or budget limit.
All out. Begin with adding the requirements with assigned duration or cost to the calendar or budget. Stop when the calendar dates are met, or the budget limit is reached.
Selective. Identify high-priority requirements added to the calendar or budget. Add or remove requirements to meet the calendar date or budget limit.