This post is also available in: German
In projects with a fixed timeframe, it’s vital to understand the relevance of individual tasks to work at maximum efficiently and meet deadlines. The MoSCoW prioritization or MoSCoW method is a popular visual roadmap used to help identify and manage competing priorities. Because of the collaborative design of the template, cross-functional teams can use the simple method to ensure priorities are captured from a range of perspectives. This also makes it a great tool for release planning.
MoSCoW stands for the four different quadrants of the method:
- Must-haves
- Should-haves
- Could-haves
- Will not have at this time
Let’s take a look at exactly how the MoSCoW method works.
When should the MoSCoW Prioritization Method be used?
For best results, the method should be seen as a collaborative effort with individuals across departments. This will allow the session to be more wide-ranging and include priorities from various angles, not just the tech or development team. To ensure the collaborative session runs smoothly, use Conceptboard’s ready-to-use template, and everyone in the session can add ideas, comments and thoughts in real-time for everyone to see.
Because Conceptboard is a cloud-based application, the template will be saved automatically, so it can be restored to changes down the track to be updated or reviewed.
How to use our MoSCoW prioritization method template
If you’re ready to get started, simply open our free template below. You can then invite team members to collaborate by sharing a link to the board- it’s that simple.
According to the MoSCoW Method, you will need to allocate tasks into the following four categories:
Must-have initiatives
The first step is identifying the must-haves for your product. These are the essential components that must be included in the release to ensure it functions. For example, an online store might list an online checkout facility as a must-have.
To help you separate the must-haves, ask yourself these three questions:
- Will the product work without this?
- Is there a simpler way to accomplish this?
Should-have initiatives
These are the elements that are just below the above category in terms of importance. They are very important to the value and purpose of the product, but it can still function without it. So they would most likely be included in the second release, once the basic functionality has been proven.
Could-have initiatives
Things that would be nice, but certainly not essential, belong In this category. They are the extra elements that don’t directly affect the functionality of the product, but may improve customer satisfaction, reliability or increase the options. Often, the things that are big projects with small impact belong in the category.
Will not have (this time)
This final section is one of the key differentiators with the MoSCoW method compared to others, as it asks teams to list features that will NOT be included. This is important as it can help avoid the feeling of overwhelm, and can help the team to accurately predict workload and manage delivery expectations.
While some of the items on this list may be looked at further down the line, perhaps in the next round of updates, some may simply not be worth the time, effort or cost and thus will never happen.
Agile experts suggest that for a typical project, you don’t want to have more than 60% effort allocated to must-have tasks, and usually around 20% effort in the could-have basket. This helps maintain a comfortable level of risk and predictability of the project. If 100% of tasks end up in the first two quadrants, then the flexibility derived from the MoSCoW method would no longer be useful. In the case of tight budgets or timelines, there would be no lower priority requirements that could be dropped to focus on the must-haves. Furthermore, be mindful that team members aren’t excessively prioritizing tasks that seem more interesting than important.
The online whiteboard built for agile teams
Make sure you explore our vast library of ready-to-use templates for all your Agile ceremonies, design thinking or brainstorming sessions.
