MoSCoW prioritization is a popular prioritization technique for managing requirements, part of the Dynamic Systems Development Method (DSDM) techniques and stands for “Must, Should, Could, Won’t”. It is one of the simplest methods to evaluate the importance of each task. This method is commonly used to help key stakeholders understand the significance of initiatives in a specific release.
Features
The MoSCoW analysis requires breaking down all story points into four groups.
Must: These features are mandatory. Neglect any of them and the current sprint most likely fails.
Should: Features here can be described as great to have, but not top priority. Simply put, they don’t have much impact on delivery success now, though eventually, they must be implemented.
Could: These are small-scale improvements that don’t take considerable resources, but they aren’t essential. Their absence won’t affect almost anything, or at least wouldn’t do any harm to the release.
Won’t: Sometimes, the “W” in MoSCoW is used to stand for “Wish” instead of “Won’t.” But always these items are of the lowest importance. They don’t match stakeholders’ current challenges, needs, and requirements. Thus, they may be easily omitted or rescheduled for future releases.
What to do first?
Before running a MoSCoW analysis, a few things need to happen. First, stakeholders and the product team need to get aligned on objectives and prioritization factors. Then, all participants must agree on which initiatives to prioritize.
At this point, your team should also discuss how they will settle any disagreements in prioritization. If you can establish how to settle disputes before they come up, you can help prevent those disagreements from holding up progress.
Finally, you’ll also want to reach a consensus on what percentage of resources you’d like to allocate to each category.
With the groundwork complete, you may begin determining which category is most appropriate for each initiative. Let’s break down each category in the MoSCoW method further.
Pros of MoSCoW prioritization
Given such operational friendliness, the benefits of MoSCoW prioritization are quite obvious.
Simplicity. The MoSCoW method doesn’t require deep understanding or complicated calculations. So, it’s easy for a team to keep in line with the whole prioritization process using a simple language. This promotes mutual understanding between team and stakeholders. Scheduling with MoSCoW is fast and transparent.
Agility for scheduling and implementation. Since this prioritization method has no strict time limits, except for the Must-have category, it allows for changing suitable timeframes per feature. That way, a team can adjust feature deliveries or releases on favorable terms.
Cons of the MoSCoW approach
With such simplicity come some challenges.
Lacks a clear consistency of implementation. Though the priorities may be easily set, the MoSCoW method does not introduce any sequencing of tasks and lacks planning. At the end of the day, it might put the entire release at risk.
Lack of big picture focus. With MoSCoW suggesting the most-to-least critical requirements or features, the stakeholders still might not see a full picture of priorities. If the focus must be concentrated on key features that are important for a business, MoSCoW may mislead the team. So, the stakeholders have to allocate business goals by themselves.
Creates imbalance between the required and slightly desirable. Often, the blurred lines between categories make it hard to decide on features that go into, say, Must and Should lists. That’s why floating tasks between all categories should be approached with great thought and care.
Ambiguity over timing, especially on the Won't have category: whether it is not in this release or not ever. Oftentimes, "Won't have" becomes "must have" during development.
Potential for political focus on building new features over technical improvements (such as refactoring).
When to use MoSCoW
The MoSCoW method is simple but it’s not always effective. For instance, if you have a complicated backlog with many time-sensitive releases, consider choosing other methods or complementing MoSCoW with 2 or 3 more comprehensive approaches.
On the other hand, it’s quite reasonable to use MoSCoW with small products that don’t have many technical limitations and dependencies. It has a straightforward set of requirements used to determine the importance of initiatives. The MoSCoW requirements help teams take a strategic, orderly approach to prioritization. This system cuts down on wasted time, arguments, and misdirection. It also omits as much bias as possible from the process so that everyone involved can take an objective view of the requirements at hand.
Source: Medium
