In our most recent article on this blog, we discussed how the agile methodology for software requirement gathering called user story can be used to express business goals and plan and estimate project deadlines.
As a software development tool, this methodology provides a good framework for collecting requirements and keeping up with new and emerging ones.
Similarly in this guide, I would like to shift your attention briefly to another popular technique.
This time, our goal is to see how the requirements gathered with user stories from the last article can be prioritized for maximum return on investment with something called MoSCoW analysis.
Understand MoSCoW Analysis
MoSCoW Analysis (also called MoSCoW Prioritization, method, technique) is a four-prong approach to prioritizing software features that can help determine which project requirements provide the best ROI.
In MoSCoW, the capitalized words M.S.C.W represent the four categories of initiatives that a project must be divided along.
You read them as must-have, should-have, could-have, and won’t-have.
The o’s are meant to aid the pronunciation of the acronym.
The word has its roots at Oracle where software development expert Dai Clegg invented them.
When applying the MoSCoW technique, teams partition their project’s features along these 4 lines:
M: Must Have
As stated in its name, this category suggests project features that are a necessity to have. They represent the non-negotiable needs of the project that have been considered fundamental to the project’s existence. An example of these kinds of requirements is the need to have two-factor authentication or encryption for a financial technology application to provide rock-solid security.
To evaluate requirements that fall into this category, ask your team these questions:
- Will this project still function effectively without this particular feature?
- Would leaving out this requirement mean that our project will become non-compliant with regulations?
A good rule of thumb to determine whether or not to place a requirement into this category is to ask if there’s a workaround for the implementation of the requirement without affecting the project. If this is the case, the said requirement should be moved into the should-have tier.
S: Should Have
This tier as mentioned in the last paragraph should contain requirements that are nonetheless essential to the project or release but that are not vital.
This tier holds the type of requirements that although add significant value to the project, are optional for its functioning.
An example of these kinds of requirements would be non-functional requirements defined during the requirement-gathering process with user stories. Others would be performance boosts and bug fixes.
Assessing whether a requirement falls into this category is easy. Ask your team, how much pain would leaving out this requirement cause? As in, how much business loss would leaving a requirement have?
C: Could Have
Could have requirements as the name of the category implies are the types that would make a fair share of business value but like the tier above are not necessary to have.
Because of how unimportant they are, requirements in this tier should be given less priority compared to the must-haves and should-haves.
W: Won’t Have
As the least important tier of the process, this tier is often mainly used to manage expectations and time during development. Requirements that go here include the ones that perhaps would have made it into the could have category if not that their implementation extends past the project’s scope.
Now that you fully understand the MoSCoW framework, let’s look at why and how it helps with ROI and is considered one of the best ways to prioritize software requirements.
Why MoSCoW Analysis is important
Agile projects, especially Scrum ones use a product backlog, which is a prioritized list of the functionality to be developed in a product or service.
Items in this product backlog (usually user stories) are further broken down into small bits called iterations that focus on completing specific project elements in work sessions called sprints that typically last from between two to four weeks.
During this process of breaking down the product backlog into iterations, the MoSCoW method is what agile practitioners use to determine which elements of the product backlog the team should prioritize and which can be put on hold.
The implication of this is a process that enables teams to quickly deploy solutions with an efficient use of resources.
Another advantage of the MoSCoW framework is how it aligns project stakeholders from the inception of a project since the method mandates reaching a consensus on the percentage of resources to allocate to each category’s requirements.
How Your Team Might Use MoSCoW
Perhaps the biggest plus for using the MoSCoW technique for software requirements Prioritization is that it allows your team to determine how much effort should go into building features from the first two categories of the framework as opposed to the third or the last.
So, if your team could benefit from being laser focused on clearly defined objectives for any project, then adopting the MoSCoW prioritization technique should be considered.
The technique is highly effective for teams who want a high-level view of the importance of project requirements.
Are you looking for help building your product idea? Reach out to us through our software development garage service. We help businesses like yours build and deliver big product ideas. See our case studies for more details.