On most projects, we talk about requirements and features that are either in scope or out of scope. But to manage those requirements effectively we also have to prioritize them. And this is where the MoSCoW technique comes in. In addition, you can read more about the acceptance criteria here.
" style="height: 402px;">
Let me explain what M, S, C, and W stand for.
- M is a must-have requirement. Something that’s essential to the project and that’s not negotiable.
- S is a should-have requirement. Something we need in the project if at all possible.
- C stands for could-have. Something that’s nice to have in case we have extra time and budget.
- W is a will not have requirement. Something that’s out of scope, at least this time around.
Why Use MoSCoW Technique for Requirement Prioritization?
Using the MoSCoW technique gives us a more granular view of what is in or out of the scope of the project, and it helps us deliver the most important requirements to the customer first. In other words, it helps you to manage your client’s expectations. And as you will come to see, the MoSCoW technique can also be used to delegate work and to be explicit about what needs to get done and what doesn't need to get done.
Whenever I train people in the fundamentals of project management, I always teach them the MoSCoW technique. And without a fail, it ends up being one of the most useful techniques, due to its applicability and simplicity. It can even be used outside of the project space. And, if you still wonder how we arrived at MoSCoW, then we’ve simply added two o’s to turn the four letters into a memorable city name. How to Use MoSCoW Technique for Requirement Prioritization?
" style="height: 514px;">
Let us look at an example of how to use the technique in practice. I would like you to imagine that your job is to project manage an upcoming conference. This is a yearly conference where delegates will come to network and hear industry experts talk about sustainability in project management.
M- Must
As you meet with the organization behind the event, i.e. your client, you ask them what their must-have requirements are for the conference. You are curious to know everything you must deliver to them for them to be satisfied. Your client responds that the event must be held at an indoor venue within five kilometers of the city center and that it must be within the allocated budget. It must be able to host 150 people and it must have facilities to serve lunch.
S- Should
You then ask your client what there should be at the event if at all possible. They answer that you should arrange for three speakers in the morning and three speakers in the afternoon. All of them should be recognized within the industry, if at all possible. In addition, you should make time for the delegates to network with each other during lunch, and lunch should, ideally, be a sit-down affair with hot food. Finally, each delegate should receive a goodie bag upon arrival.
C-Could
You furthermore enquire with your client what there could be at the event. i.e. what are some nice-to-have requirements, which you could incorporate? You’re not promising to deliver those requirements but in case you have extra time and budget you can look into it. It turns out that your client would like to have a famous sports or businessperson open the conference. But it’s not essential and only possible if the budget allows it. They also think that it would be nice with a panel discussion on sustainability at some point after lunch, but it isn’t essential.
W- Would
You finally ask them what there will not be at this event, i.e. which requirements are firmly out of scope. Your client answers that there will not be multiple tracks of speakers and that there will not be any alcohol served at any point during the day. They also specify that this year there won’t be a second day of in-depth workshops taking place.
Using the MoSCoW technique in this way to categorize all the project’s requirements is a very user-friendly method, which your client will be able to easily understand. Initially, your client may say that everything is a must-have requirement, but when you explain that must-have requirements come with a price tag they will understand that they can’t have everything unless they increase the budget and give you more time to deliver it.
When you plan your project and put together the project plan, only include the must-have and should-have items. This is what you’re promising to deliver. You’re not promising to deliver the could-have items. They can go on a separate wish list. Also, take care to properly document the will-not-have requirements. You may think that you can forget about them because they are out of scope. But, it’s necessary to document them as you may have to refer back to them later.
Example of using the MoSCoW technique to describe features of a requirement
What I really like about the MoSCoW technique is that you can also use it at a more detailed level to describe the features of a requirement. Let’s say for example that you have delegated the goodie bag task to one of your team members. That’s the little bag each participant will receive when they arrive at the venue and which normally contains a few freebies. It’s the team member’s job to gather the detailed requirements for the goodie bag and to physically produce it.
As you’re delegating the task, the team members would like to know what your expectations are and what they must deliver to you at the end. You should explain to them all the information required clearly, such as:
- The requirements (M):
There must be 150 goodie bags
Each bag must contain a copy of the event program and
Bag as well as the event program must be made out of recyclable materials - The deliverables (S):
There should be two free branded items inside, such as a pen and paper, if at all possible. - Furthermore, explain that (C):
The bag could contain something sweet, like mints, but only if a suitable sponsor is found.
The bag could also contain a small bottle of water as a nice to have. - Finally specify that (W):
The bags will not contain any alcohol and the combined weight will not be more than one kg.
Unleash your potential with PMP certification. Enroll in our PMP certification class and become a project management expert.
Whose Responsibility is to Prioritize?
Business Analysts are mainly responsible to take up the most complex requirements and break down them into simple tasks that can be implemented by anyone. But, BA alone can’t do the prioritization alone. He/she needs to bring several stakeholders into the process and get their approval on the requirements priority. It is essential for BA to understand the dependencies between the requirements before prioritizing them.
Benefits of using the MoSCoW technique for Business Analysts
The BA can make use of any prioritization techniques to prioritize the requirements thoroughly. But, MoSCoW technique is the most effective one to use among all the other prioritization techniques available. Some of the benefits of using MoSCoW technique for Business Analysts is shown in the figure below.
Drawbacks of MoSCoW Prioritization
MoSCoW is a priority for many product and development teams, although the strategy may have some drawbacks. Here are a few instances:
Sometimes tasks are assigned to the wrong categories due to inconsistent scoring. MoSCoW is frequently criticized for its lack of an impartial approach to comparing initiatives to one another. Your team will need to apply this process to your analysis. The MoSCoW technique only functions if your team adopts a standard scoring methodology across all efforts.
Items could end up in the wrong categories if all pertinent stakeholders are not included. To decide which of your team's activities are absolutely necessary for your product and which are merely desirable, you'll need as much information as possible. For instance, you might require feedback from a member of your sales staff regarding the significance (or lack thereof) of a proposed new feature to potential customers. Without feedback from all pertinent stakeholders, your team may choose poorly where to place each endeavor, which is a drawback of the MoSCoW technique.
Team bias can reduce MoSCoW's efficacy by supporting (or opposing) efforts. Your team members might be influenced by their opinions on particular initiatives because MoSCoW lacks a framework for objectively evaluating initiatives. Using MoSCoW prioritizing carries the danger that a team may erroneously think that MoSCoW is an impartial way to evaluate the things on their list.
They discuss one initiative, determine it should have been done instead, and then move on to the next. On the other hand, your team will need a consistent and impartial system for rating every proposal. The only way to lessen your team's prejudices in favor of or against things is to do this.
Conclusion
As we can see that we can prioritize requirements with MoSCoW technique at a high level but also at a low level to specify the detailed requirements, or features, of a product. When you use it at a low level it also helps you to delegate tasks better to team members and to set expectations. Are you ready to give it a go?
