How to use the MoSCoW method to build an MVP?

What do you think about when you hear Moscow? The capital city of Russia? Obviously. One of the characters from the La Casa del Papel series? Most probably. But what about the MoSCoW method? It’s spelt funny. That’s for sure. Do you know what it is and how it can be used in product development, specifically for building an MVP? You will once you finish reading. We cannot guarantee this post is going to be as attention-grabbing as the series. Still, we will do our best.

What is an MVP?

An MVP, or minimum viable product, is a basic version of a product that gets launched to early customers with the goal of gathering feedback and validating a product idea. It’s essentially the simplest usable version that solves a core user problem.

The idea behind an MVP is to avoid spending a lot of time and resources developing a product that nobody wants. When you get something out to users early, you can learn what features they actually value and use this feedback to improve your web or mobile app.

What is the MoSCoW Method?

The MoSCoW methodology is sometimes called the MoSCoW prioritization method or the MoSCoW analysis. It’s easy to figure out. It is used to analyze and set priorities. It goes hand-in-hand with Agile – a software development methodology that emphasizes iterative development, flexibility, and early feedback.

But why does it go by the name of the capital city of Russia? The answer is it does, and it doesn’t. It is an acronym, and the meaning of the letters is explained in the picture.

In other words, it is named MoSCoW in order to make it easier to remember. How pragmatically! You’ve already memorized it, haven’t you?

Product development starts with a vision. It can be a vague idea of what the founder wants or a very detailed plan. This vision is then confronted with reality, ideally in the form of market research. At this point, it might happen that there is already not much left of it.

Yet, if the idea was good and there is the market for it, it’s time for the final trial by fire, i.e, preparing an MVP and launching. When the actual development starts, it’s the moment to use the MoSCoW method (or at least to use it for the first time in the project).

How to prioritize features for MVP development roadmap?

It’s essential to point out that the MoSCoW prioritization technique is only useful when the deadline is fixed. But why prioritize when there is no deadline? In such cases, you just code everything, and the project is ready when it’s ready. Having said that, we can’t imagine proposing something like this to the client. You wouldn’t even bother to stay till the end of the meeting, would you?

No priorities – no good

Meanwhile, in the reality of specific deadlines, it’s often the case that not everything can be delivered within a set timeframe. It’s obvious that you cannot let the software development company just pick random features they like or ones that are easy to code. You have to prioritize the work in a smart and pragmatic way.

Hiring a Product Owner

There are several methods to do it. You can hire a Product Owner who will be responsible for declining all the requests. However tempting this approach might be, it doesn’t resolve the issue of prioritizing tasks that are already in the backlog. Plus, the requests sometimes come from you, which makes this situation uncomfortable. All in all, hiring a Product Owner is an excellent idea, but it doesn’t solve all of the problems.

Cost of Delay

Another method is the Cost of Delay. We wrote the whole article about it. You should read this if you want to know the costs of lack of prioritization. You can find a very user-friendly table there, so we think there is no need to quote it here. TL;DR is that you want and need to set priorities somehow.

Benefits of the MoSCoW method

Finally, coming back to the MoSCoW method, it allows you to talk to the software agency in a language that is intuitive and natural to all parties. Should there be any other stakeholders they are likely to understand must, should, could, and won’t perfectly well too. It is an undeniable advantage that the categories are very self-explanatory. You neither have to learn what A, B, C, and D categories mean nor have to translate the human language to some code names known only to the development team.

What do the letter M, S, C, and W stand for?

Please don’t frown on this headline. We know that you know what the letters mean. We just feel that, no matter how self-explanatory they might appear, those categories need more detailed descriptions. What we think we should specify here as well is that features can move between categories even within the current sprint. All that is needed in such a case is the agreement of all the stakeholders. Needless to say, that should be an exception and not a standard that happens whenever the deadline feels dangerously close.

Must have

The must-haves are features that are absolutely essential for your product to work. In the case of MVP, they are crucial either to the product’s very existence or for fulfilling the UVP (Unique Value Proposition). If the development team fails to deliver the items from the must-have in the current sprint, the sprint should be considered a failure. When talking about creating an MVP, things get even more straightforward. MVP is not ready until all the must-have features are ready.

Features that belong to this pool are usually the easiest ones to identify. After all, it’s not that hard to tell what is the absolute bare minimum. What is usually much more challenging is identifying features that should be dropped from must have to further categories.

The temptation of adding more and more items that appear to be very important and needed from the very beginning is sometimes hard to resist. After all, it’s not easy to come to terms with the fact that the MVP built upon a great vision is only an MVP. The first version is never perfect and complete. In fact, it shouldn’t be.

Should have

Should-haves are all those requests initially included in the must-have group but dropped after careful consideration. It’s a pool for features that do not necessarily constitute the essence of the product but influence the usability and overall experience.

It’s worth remembering that the should-have features not implemented in the current sprint are likely to become must-have requests in the next one. Moving items between must-have, should have, and could have is often not about deciding if they are going to be implemented, but rather when. This is an important statement to keep in mind. Until something doesn’t land in the won’t have category, there is still a chance it’s going to be done eventually.

Still, you have to remember that the should-have features are only slightly less important than the must-have ones. They should be added to your product at some point. On the other hand, if something is more of a desire than a requirement, it should land in the third pool – the could have category.

Could have

Could-haves are the features and requests that add some extra value on top of what is needed for the product to function. It constitutes the list to which developers refer once they are ready with everything from the must-have and should have groups. Pragmatically speaking, the possibility it will happen is not great. Yet, it’s nice to have something prepared. Plus, the list of could have features will probably come up pretty naturally.

Why do we say that? In the course of discussing with all the stakeholders which features are crucial and which are not, you will most probably come across at least of few requests that someone has difficulties to drop. Those are precisely the ones that land on the could have a list.

They are not in any way crucial to the overall performance of your product, yet, stakeholders are not ready to completely let go of them and put them in the won’t have a category.

In a way, you can look at a could have a pool as a waiting room for features. Some of them will eventually make it to the could have and must have categories. Others will be dropped entirely and go to the won’t have a list.

Won’t have

The won’t have category can be understood in two different ways. Both self-explanatory:

• Won’t have altogether
• Won’t have it for now

In the first case scenario, putting requests and features in this pool is saying “no” to them. It might happen when the idea is too complex to code, or coding it is not worth the time necessary to do it. After all, the pragmatic approach is to invest as little as possible in your MVP. In such cases deleting items from the backlog, or as we like to say, maximizing the amount of work not done, is a critical skill. We understand that it’s not easy. Yet, we believe you’re going to thank us later.

Anyway, if the idea of giving up on some features is unbearable to you, you can agree with your dev team that won’t have will stand for won’t have for now. You can treat it as a temporary tradeoff and revisit this list after some time. It might happen that at least some of those features will eventually find their way to the market.

How to do it?

It all looks neat and easy, but how do it in practice? This is a very pragmatic question to ask. Let us provide the answer consisting of bullet points:

• Gather all the stakeholders (founders, investors, product owner, development team) in one place, or given that’s after 2020 in one time on-line.
• (Ignore the development team complaining about having to take part in a meeting.)
• Write down all the features planned for the MVP or the next sprint. At this point no restrictions are necessary, just brainstorm freely and write down everything stakeholders deem important.
• Discuss and identify the key features that should go into the must-have category. When it’s done, ask the development team or the Product Owner to have a closer look.
• Move the ones that dropped from the must-have category onto the should have list. Brainstorm and discuss again.
• Take a look at your should-have list. Is there anything you should add? Is there anything you can remove? Discuss it. Push the chosen items further down to the could-have pool.
• Repeat this process once again with a could-have list. Is there anything that can be removed?
• Put the rest of the items on the won’t have a list. Brainstorm and decide whether the category consists of the requests you want to drop or just postpone.
• Go through your categories once again. Is there anything that can or should be moved? Pay attention to the fact that the preferred direction is to move things down in priority.
• Congratulations! You’ve just prioritized the tasks.

Discussion

Is the MoSCoW framework a golden solution for every single company and project? It probably isn’t. Some points of criticism include the fact that it doesn’t offer much help when choosing between tasks of the same priority. In our opinion, the solution might be to implement another method. The Cost of Delay mentioned before seems to serve such cases perfectly.

MoSCoW method is also criticized for bringing focus to building new features over code maintenance and refactoring. Another point that is made against the MoSCoW method is that there are no measurable metrics behind sorting issues into categories. Well, in our opinion, those two points are interconnected. If there are no hard metrics, it’s up to the team what comes next. Whether it’s going to be implementing new features or focusing on code to improve the overall performance with vague criteria, it is possible to shift focus even from sprint to sprint if it’s needed.

Summary. MoSCoW prioritization method

In a way, the MoSCoW method is similar to the character from the Money Heist series. It’s not spectacular, it looks nice and friendly, yet it is perfect for the job. It might happen that you will have to combine it with other methods to achieve even better results. Yet, it’s still an excellent way to start. Intuitive names of the categories let everyone use the method from the very beginning. There is no time lost on learning specialized vocabulary and explaining the rules. Once the right people are at the meeting, you can start prioritizing right away.