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 prioritise them. And this is where the MoSCoW technique comes in.
Let me explain what M, S, C, and W stand for.
Why to use MoSCoW technique for requirement prioritization?
Using the MoSCoW technique gives us a more granular view of what is in or out of 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?
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 to hear industry experts talk about sustainability in project management.
As you meet with the organisation 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 kilometres of the city centre 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.
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 recognised 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.
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 budget allows. They also think that it would be nice with a panel discussion on sustainability at some point after lunch, but it isn’t essential.
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 categorise 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.
An 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 them all the information required clearly, such as:
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 in 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 MoSCoW technique for Business Analysts
The BA can make use of any prioritization techniques to prioritize the requirements thoroughly. But, MoSCoW technique is the 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.
As we can see that we can prioritise 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?
Your email address will not be published. Required fields are marked *
Agile can be loosely described as a set of predefi... Read More