MoSCoW Prioritization is a tool for establishing a hierarchy of priorities during a project. It's based on the agile method of project management, which aims to strictly establish factors like the cost of a product, quality, and requirements as early as possible. “MoSCoW” is an acronym for Must-Have, Should-Have, Could-Have, and Won't-Have, each denoting a category of prioritization.
MoSCoW Prioritization solves one of the main problems of less robust prioritization tools by laying out specific definitions for each level of priority. When something is in the "Must-Have" level of MoSCoW, it's immediately clear to everyone on the team that this feature cannot be overlooked during the project's development.
MoSCoW Prioritization should be used early in the project management cycle, though it shouldn't be your first step. You need to have project requirements laid out before you can start organizing those requirements by priority. So the sooner your team can lay these priorities out, the better.
Although there is an initial phase of MoSCoW where your team will categorize all of the project's requirements by priority, this doesn’t mark the end of the MoSCoW process. Each time a milestone is completed, the remaining milestones should be (briefly) reevaluated.
For example, you may have Requirement X that falls under the Could-Have category during your initial MoSCoW meeting. Once you complete a few Must-Haves, however, you may look at Requirement X differently, deciding that you do need to implement it more urgently, or that it doesn’t add any value at all.
An element of flex is good during development, though you shouldn't change your MoSCoW model so dramatically that it becomes useless. The secret lies in finding a sweet-spot between iterative assessment, and a structured way of working.
As mentioned, the MoSCoW model consists of four components: Must-Haves, Should-Haves, Could-Haves, and Won't-Haves. Though the title of each category makes its purpose pretty clear, we're going to dive a little deeper into each so that you can better utilize them.
These product features should be the easiest to determine. If you were designing a car, these would be tires, engine, and fuel. If you're creating a budgeting service, then you might consider the ability to integrate with a user's bank account a Must-Have component.
In other words, these are the minimum requirements for your project; they are non-negotiable. If you find yourself having a hard time determining which features to place in this category, simply ask yourself, "Will the project fail if this feature/milestone/component isn't met?" If the answer is "yes", then this is a Must-Have component.
Your project's Should-Haves are the features that are not essential to the project's success, but will add substantial value nonetheless. These features are more focused on fulfilling customers' wishes and expectations, rather than meeting their basic needs.
Returning to our car example, a Should-Have component would be the air conditioning system. This isn't required to make the car run, but a car without an air conditioner would be a tough sell. Like Must-Haves, you want to try and meet all of your Should-Have milestones by the end of the project.
This is the catch-all category for features that are neat, interesting, or fun, but that don't necessarily serve any greater purpose. These are the comfort items — the bonuses — of your product. You may notice that this area is where the most shifting happens during the project, with features moving from this category into Won't-Haves and Should-Haves.
To determine if a feature is a Could-Have or a Should-Have, consider how it will impact the value of your product to customers. In most parts of the world, a car without air conditioning will be nearly impossible to sell as a "good" car. However, a car without a parking camera, though an immensely useful feature, is unlikely to dramatically reduce the perceived value of the car. So, in this category, you'll put features that would sweeten the deal, but not make or break your product’s success.
Finally, we have the Won't-Haves. This category is likely to fill up with ideas as you get further along in the project development cycle. Essentially, this is where you put the features you would like to include in your product, but for some reason can't.
You either don't have the tech, talent, resources, or confidence to try and implement a certain component into your product. Instead of throwing this idea in some notebook and forgetting about it, you can place it here, where you can revisit it later. You may find that some of your Could-Haves and maybe even some Should-Haves are actually Won't-Haves due to unexpected limitations.
There are several reasons why the MoSCoW method is useful for creating a solid product. First, it helps you create a timeline for your project by determining what needs to be completed first. Everyone knows what the most important features are, giving the whole project a sense of clarity.
Second, the MoSCoW approach is excellent for setting project expectations, both for the team and the stakeholders. It gives investors a good idea of what they can expect from the project, as well as a clear idea of what each feature is going to cost.
Third, implementing MoSCoW into your workflow helps keep the vision for the project on track. When brainstorming with colleagues, stoking your creativity, and trying to push the boundaries, it's natural for your team to step outside of the project's requirements and limits.
While this is good for the drawing board, it's not so good when you're actively developing the product. MoSCoW provides everyone with a clear checklist of what they need to accomplish. as opposed to a vague and multi-faceted vision.