Almost every software team will, at some point, face the problem of prioritizing features. The MoSCoW method can be used to prioritize work effectively, and this article describes the technique when it should be used and how.
Every project has limited time and resources, so you need to spend your time on the most important things. However, there are always many essential items that could be done next in a given situation.
On top of this, changing priorities means you may have different people with different preferences each time your priorities change. This leads us to two conclusions: Your priorities must remain constant over time. Our priority list needs to prioritize items so that everyone can understand and agree.
Now that we know what the letters in MoSCoW mean let’s look at some examples. Must-Have This means something if it isn’t done, you will fail to be successful at the project must have something done by a certain point; otherwise, it could cause severe negative consequences for the project or company.
You can’t start testing until you’ve designed all of the features must-have features designed before you start trying should have These are good things to do early on, but they aren’t necessary (i.e., “I’ll need these eventually.”)
This would be good to do in the future, but there are higher priority items in this release so it won’t be done should have. These are things you can allocate some time for if you have some extra capacity on your project plan.
These are items that we’d like to get to soon. However, there is a more important item right now, so unless more capacity opens up, these features likely aren’t going to happen could have These are ideas or feature requests from our customers and users. They may not fit into the overall theme of the product roadmap, but they’re still valuable feedback nonetheless.
We need a way to prioritize features without having too much discussion about priority. The MoSCoW method is an excellent tool for this. Now that we have a prioritization scale, it doesn’t matter what order you put the letters in because they mean the same thing. This may be counter-intuitive if you’re not used to it yet, but once you get the hang of using MoSCoW, it will become second nature and well worth its simplicity.
MoSCoW is easy to use and remember; however, there are some variations in applying it from time to time. Some companies write the list as Must have, should have, could have, and won’t have. Other companies write Must Have as the top priority and then have a priority list from 1-3 or a combination of Must Have/Must Have/Should Have.
It’s best to use MoSCoW when there is a detailed long list of potential features or enhancements, and you need to prioritize them for development release planning purposes. It’s easier to look at a prioritization scale than it is to look at an entire list of ideas on which items are most important, so this scales very well from small projects up to large enterprise solutions with hundreds of features and enhancements.
MoSCoW can be used in almost any situation where you’re trying to prioritize things, especially if you have too many ideas and not enough time to work on them all. So, if you’re prioritizing enhancements for your project plan or adding items to a backlog list, consider using the MoSCoW method, so it’s easy to prioritize features without having extensive discussions about priority.
Prioritizing features is a great way to move your product forward. MoSCoW is a simple method of prioritization that will work well in almost any situation where you need to prioritize features or enhancements on your product roadmap. Following is the way to go about it.
You can use a simple spreadsheet to add all of your items in one column and then populate your MoSCoW list in another column. This is especially helpful if you’re trying to prioritize planning purposes (i.e., product roadmap prioritization). You can then sort by the MoSCoW value, making it easy to find the most important stuff to work on next.
To determine the appropriate level for each item, think about what could happen if we didn’t build this and how bad would it be? Here are some examples:
Must have – this is a top priority item. If we don’t make it, our customers won’t be satisfied, and they’ll stop buying from us. This is the most important thing to get done right away.
Should have – this will make a big difference in the customer’s use of the product, but it’s not an “all or nothing” type of request that will leave them dissatisfied if we don’t do it. However, building this feature would be better than not building it at all.
When you’re done with your prioritization work, summarize what’s left for MoSCoW listing purposes by writing down which items are Must Have/Should Have/Could Have/Won’t Have when you’re done grouping all of your ideas into individual groups.
Now you can easily prioritize everything in your list by determining what’s most important to work on next. This is a great way to figure out what should be included in an iteration or product release so that customers will have the best user experience possible.
Suppose you have too many features and enhancements. In that case, you’ll find it much easier to prioritize this way instead of trying to group them all at once without a prioritization scale. To do this efficiently for an entire list, use a spreadsheet to sort the list by priority from highest to lowest using MoSCoW as the column headings instead of writing up a big description which would be very time-consuming.
Must have – our customers expect these features, and they’re critical to their success with our product. This could be a significant customer request that needs to get done right away.
Should have – if we don’t build these, customers will still use the product, but it won’t be as effective at solving their business problems. If we prioritize doing this work upfront when we add new features or enhancements, then customers will see a more excellent value in our products because it will help them do better in their jobs.
Could have – this may improve the product, but it isn’t going to impact customers significantly. Adding this will make the customer’s life better, but they could still use our product without these changes.
Won’t have – there is no real reason to build these, and customers won’t even notice if we don’t include them in the product. While some things may not be worth doing in terms of development effort, you may want to consider adding them as an enhancement if it makes sense in context (for example: if customers demand one-off enhancements because it helps with their process).
This is a great way to prioritize features and enhancements for products, iterations, and releases so that your teams can work more efficiently and consistently by focusing on what matters most to drive maximum business value.
MoSCoW is an effective way of prioritizing projects and features without having too many discussions about priority. It also helps incorporate customers’ feedback more transparently due to its simplicity. If you haven’t used this method before, give it a try soon!