MoSCoW analysis is technique used for establishing requirement priorities where participants divide the requirements into four categories of must haves, should haves, could haves, and won’t haves.
Requirements Prioritization in Business Analysis
From a business analysis perspective, requirements prioritization is the process of understanding how individual pieces of product information achieve stakeholder objectives, and using that information, along with other agreed-upon prioritization factors, to facilitate ranking of the work.
Prioritizing requirements is an important step in managing product scope. Prioritization determines what should be worked on first or next so that business objectives are achieved in an order that best meets the needs of the organization.
Prioritization is about focusing on what adds the most value. Product information at any level, from business needs to functional requirements, can be prioritized. Prioritization also supports the allocation of requirements to iterations or releases for release planning purposes.
A business analyst might recommend prioritization, but it is necessary for accountable stakeholders who have authority to prioritize requirements to be involved in this process. Business analysts help facilitate and negotiate prioritization decisions.
Prioritization might happen iteratively or all at once on a portfolio, program, or project. The project life cycle influences the prioritization process and often dictates the frequency, timing, and techniques for performing prioritization.
Prioritization of any item at any level commonly involves two efforts and they do not have to be sequentially ordered. The first effort is when the business stakeholders, subject matter experts, or product owners prioritize requirements based on their estimated business value. The second effort is to understand the project team’s estimates of effort and the risk of each requirement.
Prioritization Schemes
Prioritization schemes are different methods used to prioritize portfolio components, programs, projects, requirements, features, or any other product information. The business analysis analysis approach identifies which prioritization schemes the team has agreed to use and when. The following are some commonly used schemes in business analysis:
- Buy a feature. A type of collaborative game used to enable a group of stakeholders to agree on prioritization by providing each stakeholder with an amount of pretend money to buy his or her choice of features, splitting the money received across features, however desired.
- Delphi. In this technique, each stakeholder provides a prioritization for the requirements set using the prioritization scheme chosen, and then the stakeholders meet together to discuss until the group agrees on the prioritization. This method is intended to reduce peer pressure or groupthink in the prioritization process or to avoid the team giving in to a voice of authority with whom they may disagree.
- Minimum viable product (MVP). A prioritization mechanism used to define the scope of the first release of a solution to customers by identifying the fewest number of features or requirements that would constitute a solution from which the customer would obtain value.
- Multivoting. A method also called dot voting because it can be performed by providing stakeholders with a prescribed number of colored dots and allowing them to vote by placing their dots on the requirements that they feel are the most important. All votes are aggregated and requirements are ranked by the number of dots/ votes received.
- Weighted ranking. A method that first requires decision criteria to be identified and weighted. Then each item is rated by scoring how well the option meets the criteria independent of other options. Ratings are multiplied by the weights and summed to arrive at the score for each item and the overall rankings.
- MoSCoW prioritization. It is a popular prioritization technique for managing product requirements. The acronym MoSCoW represents four categories: must-have, should-have, could-have, and won't-have, or will not have right now.
MoSCoW Prioritization Technique
The MoSCoW method rules are utilized to help achieve clear prioritization of product requirements. The ‘o’s in the acronym have no meaning. The remaining components of ‘MoSCoW’ as used in business analysis are defined here:
Must have
These are product requirements that are fundamental. Without them, the product will be useless. Their delivery at the end of the appropriate timebox is guaranteed. If any one of these ‘Must haves’ in the MoSCoW prioritization is not ready then nothing can be released: if it could be, then they were not really ‘Must haves’ in the first place.
As a result of this, it is important to be aware that the term ‘Must have’ covers the functionality itself in the product. It is for this reason that things can usually only be prioritized properly once a certain level of decomposition and definition of the product requirements has been achieved.
Should have
Using the MoSCoW method, these are important product requirements for which there is a work-around in the short term, or where expectations can be managed. They are things that would have normally have been classified as ‘Must haves’ in a less time-constrained situation, but the deliverable will still be usable without them initially.
The mindset of good MoSCoW prioritization is that one would normally expect to deliver, in addition to all the ‘Must haves’, a large proportion of the ‘Should haves’. The ‘Should haves’ are often described as those things that you would expect to be included within a product of this type, but whose non-inclusion would not necessarily delay the release.
Could have
These are product requirements that can more easily be left out at this point. They may well be included in this delivery if their inclusion is easy to achieve without jeopardizing the delivery of the ‘Must haves’ and ‘Should haves’.
Will not have right now
This refers to those product requirements that can wait until but won’t later. It is often useful to keep these in the initial priority list, have this since, although they are not due for delivery yet, knowledge that time round they will be coming later may influence design decisions. All of the items in the prioritized requirements list are due for delivery at some point in the project, although the total delivery may be spread over a number of increments.
The MoSCoW method provide the basis on which decisions can be made regarding the whole project, and during any timeboxes included within the project. It is for this reason that the techniques of prioritization and timeboxing are so useful when applied together.
The MoSCoW prioritization is likely to change throughout the project, in terms both of changes to requirements and of changes to the priorities themselves. As new requirements arise, or as existing requirements are defined in more detail, decisions must be made as to how critical they are to success by using the MoSCoW method.
How to use MoSCoW Prioritization Technique?
It is important that not every requirement proposed in a given timebox or project is a ‘Must have’. It is the existence of lower-level priority requirements that allows for flexibility and agility in dealing with problems that arrive and with the inevitable change of scope.
Once all project stakeholders are clear about the meaning of each of the MoSCoW prioritization levels, and there is a published procedure specifying who is allowed to change priorities, it is much easier to make quick progress through a project and to reduce delays when decisions are needed.
For example, some organizations empower team members to adjust the scope of delivery as long as there is no effect on the delivery of the ‘Must haves’ within their work package, only referring to a higher authority when the delivery of ‘Must haves’ is at risk or when a decision is required to drop a ‘Must have’ to a lower priority level.
When undertaking the MoSCoW prioritization exercise it is not unusual for there to be heated discussions as to what priorities should be allocated to various requirements, and it is particularly common for there to be a very large list of Must haves.
It is important that this situation is addressed early. This can involve spending some time explaining the specific meaning of the MoSCoW prioritization levels. Keep in mind, if a ‘Must have’ is not delivered on time then neither is anything else! A very good tip to help avoid this happening is to allocate everything initially as a ‘W’ and work backwards towards ‘M’, justifying each move.
MoSCoW Analysis Example
Consider the following example:
Requirement: to be able to view a user bank account balance.
For any proper banking system, this will be an ‘Must have’ for the first release of the system. However, if it were to be decomposed into its component parts and also considered from the perspective of various scenarios and extensions, it becomes clear that there is plenty of scope for some elements to be allocated a lower priority or left until later without jeopardizing the delivery of the basic facility to customers.
It is important not to overdo this, and to ensure that enough is initially offered to the customers for them to be comfortable while waiting for the remainder of the features to become available.
This approach is even more powerful when applied to the non-functional as well as the functional aspects of a requirement. Therefore, a more detailed definition of the requirement might lead to the following use of MoSCoW method:
Function Requirement: to be able to view a bank account balance – priority Must have.
Related Nonfunctional Requirements: Security – priority Must have; being up to date, to the latest transaction – priority Should have; availability in both Dollars and Euros – priority Could have; availability in various languages – priority Could have.
This would allow us to deliver a system on time that allowed customers to check their bank balance; while we would initially expect it to produce totally up-to-date results, the first release might need to put out a message saying that transactions performed during the current day might not yet be shown.
Conclusion
As a conclusion, there are several methods to evoke prioritization of requirements from the stakeholder community. Many business stakeholders may find it difficult to make decisions regarding prioritization, as they may see all of the requirements as equal, or at least the requirements they provided.
As the business analyst, you should drive the prioritization decisions from the business by using prioritization schemes like MoSCoW method, it establishes a set of prioritization rules which are: Must haves (fundamental to project success), should haves (important, but the project success does not rely on them), could haves (can easily be left out without impacting the project), and won’t haves (not delivered this time around).
If you have advanced knowledge and experience in business analysis, or if you are a project manager focused on business analysis, including for large projects in complex environments, then the PMI PBA® Certification is an excellent choice for you.
