Q 374. MoSCoW method is a useful tool to get an agreement on the project deliverables with the stakeholders. Explain it along with an example.

 

 

Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday.

• All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/
• Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening 5 PM as per Indian Standard Time. Questions launched on Tuesdays are open till Friday and questions launched on Friday are open till Tuesday. 
• When you respond to this question, your answer will not be visible till it is reviewed. Only non-plagiarised (plagiarism below 5-10%) responses will be approved. If you have doubts about plagiarism, please check your answer with a plagiarism checker tool like https://smallseotools.com/plagiarism-checker/ before submitting. 
• The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term

MoSCoW Method

While creating a product or running a project there are lot of specifications and solutions which the project team can drive to achieve the outcomes or the desired objectives.  While it is desirable to get all the recommendations or specifications implemented but practically is not feasible to achieve availability of resources and time available in hand.

 

Running and Managing a project is all about making a choice and managing what you will, and you won’t get done in the given schedule. Without prioritization a project can become a list of endless tasks and no control over the timelines and benefits may shrink due to inclusion of non-critical deliverables being prioritized.  

 

There are different approach and methods to prioritize  deliverables. One of such method is  MoSCoW method.  It is used for defining and managing requirements, tasks and deliverables in a project.

Under MoSCoW method requirements/deliverables are categorized into 4 buckets:

Must-Have Deliverables/Deliverables

·       This is the minimum outcome which a project must deliver. Even if the project has to undergo changes or cut due to other business requirements or demand these are the minimum deliverables which the project must deliver on the target date for the project to be closed as successful. Delay on these deliverables will jeopardize the project.  It is either going to take the project off track and may not meet the end goal.  Question to be asked while reviewing “must have” requirements- Will this project be successful without this feature?  If answer is no then the requirement or feature is “must to have”.

Example Implementation of a Sourcing system-  It should provide a functionality to raise purchase requisition, create or amend purchase order

 

Should-Have Requirements/Deliverables

·       This type of deliverable is almost as important as a Must Have, but it’s not vital to the success of the project. The project doesn’t solely depend on this deliverable. As a project leader you might not want to leave it out, as it has a significant impact on the project, but in the end, it can be done if the need arises. Again, leaving out this deliverable from scope means a lot of work⁠ from managing stakeholders to finding alternate solution as it may have dependency on must have goal.  Question to be asked while reviewing “should have” requirements- Is this requirement important and this requirement wait and picked up later or in subsequent release?  If answer is yes, then the requirement or feature is “should have”.

Example  Should provide a workflow or vendor portal where purchase order can be shared with vendor and all the queries between vendor and procurement happens over the vendor portal

 

Could-Have Requirements/Deliverables

·       The difference between a should-have requirement and could-have requirement is just the degree of benefits it delivers or alignment to the overall goal. A could-have deliverable is something which is nice to have, and you may like but is less important than a should-have. In case of contingency could have deliverables and requirements can be dropped easily.  Question to be asked while reviewing “could have” requirements- Is this requirement necessary for the core function of the project or product?  If answer is no then the requirement or feature is “could have”.

Example  E invoicing to happen from the tool itself via PO flip

 

Will Not Have

·       These are all the requirements and deliverables those are collected at the brainstorming stage but are not finalized due to priorities or are not feasible to be picked up for implementation. These are all noted down so that can be attacked during subsequent releases.   It is important to place all these requirements under “will not have” to ensure teams and stakeholders know that these are not a priority for this project and if these come up later can be shown that they are kept out. This allows team to focus on the requirements that are important to the project. Question to be asked while reviewing “will not have” requirements- Will this requirement has any importance to be prioritized with the current release?  If answer is no then the requirement or feature is “will not have”.  This is Wishlist for the team.

Example Catalogue purchase through the system or implementation of P Card which can be picked up as next release or addition

 

Another approach for prioritization while gathering requirements or defining deliverables for a project is Kano Model.  Again these requirements can be categorized into Delighters, Wants and Musts.  Here Delighters are good to have, Musts are Must Have and Wants are Should have.

MoSCoW method

 

MoSCoW method is a prioritization method that was developed by Dai Clegg in 1994 for use in Rapid Application Development (RAD). It is also known as MoSCoW prioritization or MoSCoW analysis.

The term Moscow itself is an acronym from the first letter of each of four prioritization categories:

• M - Must have 
• S - Should have 
• C - Could have 
• W - Won't have

The interstitial Os are added to make the word pronounceable. While the Os are usually in lower-case to indicate that they do not stand for anything, the all-capitals MOSCOW is also used.

The Moscow method is a prioritization technique used in management, Project management, new software development, business analysis to align with stakeholders on the importance they place on the delivery of each requirement.

MoSCoW Method is often used where a deadline is fixed so that the focus must be on the most important requirements, and as such is a technique commonly used in software development (agile) approaches such as Rapid Application Development (RAD). Scrum and Dynamic Systems Development Method (DSDM).

 

Source: www.kecg.co

 

MoSCow Method plotted on Kano Model of Customer Satisfaction

 

 

MoSCoW Method Example:

Project: Creation of a Professional website for a Law firm

Purpose: People can register and track their court cases

 

Below are some of the drawbacks or criticisms of MoSCoW Method:

·       Does not help to decide between multiple requirements within same priority bucket

·       Subjectivity on how to rank competing requirements: No explanation on why something is ‘must have’ rather than ‘should have’.

·        Ambiguity over timing, example- Won't have category: whether it is not in this release or won’t be considered for ever

·       Huge room for Bias- New features over technical improvements

The MoSCoW method is an approach for prioritizing requirements of project. It allows people in a project to know what work needs to be completed first and how will it help increase revenue, decrease operational costs, improve productivity or boost customer satisfaction. Also, prioritizing requirements enables project teams to understand the effort and resource requirements

 

MoSCoW method categories : MoSCoW stands for Must have, Should have, Could have and Will not have

 

 

 

 Must have  : All the requirements that are necessary for the successful completion of the project. Non-negotiable and providing minimum usable subset of requirements.

 

Should have : One level below Must have, these elements are important to project completion, but they are not necessary. If these requirements are not included in the final product, then the product will still function...however if these are included, then they will greatly increase the value of the product. 

Could have : Requirements that have a much smaller impact when left out of the project. These are relatively unimportant desrable factors and are often the first ones to be deprioritized

 

Will not have : Final category of requirements that are not a priority for the project's timeframe. This helps strengthen the focus on requirements in the other three, and also sets realistic expectations for what will not be included in a final product. Also, this category is beneficial in preventing scope creep

Pre-requisites
Before implementing this, businesses must ensure that teams agree on the project objectives and the factors that will be used for prioritization. How to settle disagreements should also be established. Then, teams should finalize on what percentage of resources will be assigned to each category. 

 

Advantages of the MoSCoW method

• It is easy to use and understand. It helps in prioritization
• It can be used for dispute resolution among stakeholders
• This can ensure that a minimum viable product (MVP) is produced.
• It can be used to set priorities at different levels of the development pipeline.
• In addition, it enables users to assign specific percentages of resources to each of the four categories. 

 

Criticism for the MoSCoW method

• There is no clarity regarding the will-not-have requirements and whether they are left out of the release or the entire project.
• We cannot prioritize requirements within the same category.
• There's no logic and emprical reasoning for why one requirement is a must-have and the other is a should-have.
• If the decision-making process is biased, the prioritization may become subjective and inefficient

 

MoSCoW method or MoSCoW prioritization is a popular prioritization tool for managing the requirements. This method is frequently used in making key stakeholders understand the importance of the project deliverables.

MoSCoW stands for Mo (Must Haves), S (Should Haves), Co (Could Haves) and W (Will not Have or Wish). The interstitial Os are added just to make the word easy to pronounce.

Project stakeholders can discuss on project deliverables and take the decision to put deliverables under these four buckets basis the priority of the deliverable in the project. In today’s fast pacing world if we see lot of tools / techniques revolve around this concept E.g. Agile Way of Software Development. In this method, key stakeholders in a project i.e. Product Owner and Development Team can discuss together and finalise the list of the features to be developed 1^st (Must / Should Have) from the overall Product Backlog Items and develop those features in earlier sprints and less priority features (Could Have / Wont Have) can be developed in later sprints or if not to be developed at all.

 

 

Origin of MoSCoW Method :

Dai Clegg, a software developer during his tenure at Oracle created this method in 1994 for RAD (Rapid Application Development) and later this method was incorporated in DSDM (Dynamic Systems Development Method used for Agile Software Development) as well. Clegg designed this framework for prioritization for time boxed projects.

How this method Works ?

Before starting the MoSCoW analysis, all stakeholders and product team must get aligned to objectives and prioritization factors. Then, all the team members must agree on initiatives to prioritize. Also, agree on a criterion or way to solve the disagreements / conflicts in prioritization. Team can also agree on the % of resources to be allocated in each of these 4 Categories.

What are these 4 Categories ?

These 4 Categories are as described in below image :

 

 

Example : Real Estate Developer along with stakeholder can use MoSCoW method to bucketize / prioritize these 4 types of items in the upcoming project as depicted below.

 

 

Example :  A Web Developer working to make a website for a bank can use MoSCoW method to prioritize the items / user stories and work as per that as depicted below.

 

Limitations of MoSCoW method :

i) Doesn't help to decide between multiple requirements with same ranking

ii) Lack of rationale on how to rank a very close or competing requirements : why something should be placed under must rather than should

iii) Ambiguity over timing, especially on the Won't have category (Whether the requirements in this category will not be there in this release or project or any of the releases or products)

iv) Prioritized items may be influenced by external factors like Political / Geographical etc.

 

 

MoSCoW method:

MoSCoW method is used to prioritize the requirements or the projects. This prioritization can be done on following categories:

·         Must Have;

·         Should Have;

·         Could Have; and

·         Won’t Have (this time)

These categories can be explained as:

Must Have:

The Minimum and Mandatory requirements come under this category. If these requirements are not fulfilling in the project, project will be considered as failure.

For example if we are manufacturing an Optical Storage Media, Writing and Reading of the optical media is the Must Have requirement. If any project in manufacturing process is not able to ensure to fulfil this requirement, the project can never be considered as successful.

Should Have:

The requirements, which are important but not necessary requirements, can be categorized as Should Have. These are the requirements, if not included; the project will still considered as complete but if included; can increase the value significantly. These requirements can be fulfilled after the delivery time.

For example, the information secure facility is a critical requirement for a service delivery work but these requirements can be put on hold for some time in current pandemic time.

Could Have:

The requirements which are not critical but desirable can be considered as Could Have requirements. These are the requirements which can improve the customer satisfaction but not necessary customer requirements.

For example, Hard Coating is used for the protection of Optical Storage Media. This hard coating protects the media from scratches, increases the life of media and so the customer satisfaction also. But this hard coating is generally not a necessary requirement by the customer and can be easily avoided.

Won’t Have:

The requirements which are least important or least critical for the project can be categorized as Won’t Have. These requirements can be excluded from the project scope with agreement of the stockholders and can be recorded for future consideration.

For example a manufacturing company has planned to move all the non critical power requirements to the Solar Power but decides not to implement immediately due to budget constraints and investing the available funds to important and critical necessities.

The MoSCoW method is an ordering technique used in management,

business analysis, project management, and software development to reach a common thought with stakeholders on the importance they place on the delivery of each requirement.

The MoSCoW stands for:

M - Must have

S - Should have

C - Could have

W - Won't have

The Os are added to make the word pronounceable.

Must have:

These are not negotiable and it’s mandatory for the team

Should have:

Important initiatives that are not important, but will add significant value

Could have:

Nice to have initiatives, it will have small impact if left out

Won't have:

Initiatives which are not a priority in a specific timeframe.

 

 

Effort distribution of MoSCoW:

 

Below is the example on MoSCoW:

 

Sr. No	Requirement	MoSCoW
A	Users can log onto the website	Must
B	Users should be able to avail of a 'forgotten password' utility	Should
C	Users can change account details	Must
D	A user can send an email to the system requesting a change to the account page	Could
E	When a user clicks on a phone number on the web page a call is made automatically from their desk phone to that number	Won't

 

 

MoSCoW method is also commonly know as MoSCoW analysis is a very useful prioritization tool.

 

MoSCoW stands for Must Haves, Should Haves, Could Haves, and Will not have or Wish.

 

MoSCow method was devised by Dai Clegg, during his tenure at Oracle.

 

How does the MoSCow Prioritization works?

 

1. First all the key stakeholders and project owners come together and decide the parameters or factors on which prioritization can be done and arrive at a consensus.

 

2. Once everyone reach an agreement the resources are aligned as per the order of priority

 

 

What are different elements in MoSCow method and what does they mean?

 

Must Haves: The initiatives are must for the team and they are non-negotiable in nature. Team has to get them done at any cost

 

Should Haves: These initiatives have lower priority than Must Have initiatives. They are important for the team or project. However are less vital

 

Could Haves: These initiatives are also called "Nice to Have" initiatives. They are not so important for the project or team and can be given de-prioritized over Must Have and Should Have initiatives

 

Will not Have: These initiatives have lowest priority and are generally discarded. There are times when initiatives which fall under "Will not Have" bucket gets into Must Have or Should Have categories.

Managing Stakeholder and delivering the outcome with utmost value with the available resources is one of the interesting and very important skill which will ascertain the future growth of the business.

It is very interesting to experience that there are far too many requirements to meet and all of them seem to be important, however, we need to prioritize to deliver those that can reap business benefits early or most immediately.  We often hear our managers saying how important a particular action or activity is, and there seems be not one but many coming in our way and with the limited resources it becomes extremely important to prioritize and communicate to our managers internally and the stakeholders to help us to help them better.

 

MOSCOW prioritization technique

 

 

 

Frequent conversations with the customer/stakeholder will help us know which is that we need to Must have, which will give us a direction to focus. This is much better technique vs only looking low, medium and high priority.

Here is how what must, should, could and won’t have can be understood

 

 

The Agile framework talks about this and how we arrive at the minimum viable product in every sprint/cycle for the engagement/project.

Keeping mind, the time and budget we should be ready to leave out the Won’t have and Could have. Rather look at Must and have and which of those should have can be delivered in a later time box rather than considering everything into on deliverable.

This priority technique will also help us to understand the features of the product and judiciously use our time and budget

As an example: I would like to bring your attention to the below picture where the focus of the coverage of the solution and effort be.

We should drive at looking at the 60% of the effort are focused on the must have and put together around 80% of it to the Should and must while there can be 20% of it considered for could have. This gives us an indication on how we need to cautiously utilize time and effort.

 

Picture credits : Google

 

MoSCoW is one of the popular Prioritization techniques which will help us to understand and manage the Priorities in a Project deliverable.  Suppose if a Product / solutions need to be developed and which has multiple features or requirement this method help us to arrange in the order of importance from Stakeholder / Customer perspective.

 

MoSCoW stands for

·       Must Have

·       Should Have

·       Could have

·       Won’t have this time

 

 

 Must Have: Must have are the product features which need be there when the product is deployed in Production.  This is Not Negotiable

 

Should Have:  This requirement is almost important to Must Have, but its not vital to the success of the Project.

 

Could Have: This requirement is good to have, but not a Mandatory and it can be launched in phase 2 or 3 of the solution. There will be an impact, but the impact is very Marginal.  This is nice to have if we have extra time and Budge.

 

Won’t have: This requirement is something out of scope for now, not having these requirements will not impact the Solution. This is a great way to avoid the Project Scope Creep by dropping some of the features of the solution which is not related to the solution and it will not impact the solution.

 

Steps for MoSCoW method:

 

·       Elicitation: Under this method objective is to have Interview / Focus Group Discussion/ Facilitated session with Stakeholders and understand the requirements and reason behind the requirement

 

·       Validation: Under this step focus is on collecting additional data and perform further study to finalize the needs/expectations from the Stakeholders.

 

·       Specification: In this step the focus is on prioritizing and formalizing the data into requirements definition report and to make sure they are tested

 

·       Verification: Finally, verify that the requirements are accurate and publish the needs and expectations of the Stakeholders.

 

Benefits of using MoSCoW Technique:

 

 

I personally applied this technique in many of the my Projects which are related to Solution/Product/Tool Development and this is a great method in terms of  collating all the Solution/Product requirement in place, have focus group discussion with Stakeholder and prioritize then as Must Have, Should have, Could have and wont have basis their impact on the final product and needs of the Stakeholders.

The MoSCoW method is a simple yet effective tool that helps project teams to decide and arrive at a consensus while discussing various things like customer needs, stakeholder requirements, product/service development, etc.

It provides a structured approach to deciding the Must have (Basic needs), Shoud have (not basic but add significant value), Could have(Nice to have things), and Won't have (things that add no value or may even do damage).

 

Let us take an example of manufacturing a new model of car.

It might be easy to decide on a few things/features as to what the car should have but at the same time it can also be overwhelming to decide on a few factors that need to be different from the competitors. Here, if the project team uses the MoSCoW method,

 

M (Must Haves) - Basic needs like seats, brakes, gear box, mirrors, ABS, etc.

S (Should Haves) - Hybrid functionality of engine, Auto transmission, etc.

C (Could Haves) - Sensor-enabled locking system, roof-opening, parking assistance, etc.

W (Won't Haves) - Very low ground clearance, Speed capacity beyond 250 mph, etc.

 

The MoSCoW is a method very similar to the KANO model of analyzing customer needs and classifying them as basic (musts), wants(desired), and exciters.

MoSCoW method basically means MUST have, SHOULD have, COULD have and WON'T have. these are basically in priority and used in supply chain and logistics.

Comparing of all 4 terms "MUST have" is very critical from customer point of view and should be fulfilled at any cost, comparatively "SHOULD have" is less critical and so on.

For Example: In your contract / Service Level Agreement with customer have "MUST have" clause and you failed to fulfill it then you should be considered fail and you will be liable for no negotiation with customer.

Moscow method is a technique used for prioritization and agreement on the project deliverables with the stakeholders on each of the requirements

The MoSCoW Letter stands for:

·       Must Have

·       Should Have

·       Could Have

·       Won’t have this time

 

The use of MoSCoW works particularly well on projects to overcome the problems associated in the prioritization

 

MoSCoW Rules:

 

·       Must Have

Must Have requirements are defined as

1.       No point in delivering project on time without this, there would be no point in deploying the solution on the intended date

2.       Cannot deliver a viable solution without it

3.       Unsafe without it

4.       Not legal without it

 

·       Should Have

Should Have requirements are defined as

1.       Important but not vital

2.       Painful to leave out, but the solution is still viable

3.       Find some kind of a temporary workaround

 

·       Could Have

Could Have requirements are defined as

1.       Desirable but less important

2.       Less impact if left out

One way of comparing or differentiating Should Have and Could Have is by reviewing the degree of pain caused by the requirement if not met the deliverable. Which can be measured in terms of value to the business or number of users impacted

In contingency, these are the main pool and first choice to drop when a problem occurs the deadline and is at risk

 

·       Wont Have

These are the requirements which project team will not be delivering on agreement with the stakeholders, In other words out of scope and may reintroduce it later.

The MoSCoW method also known as MoSCoW prioritization or MoSCoW analysi is a prioritization technique to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement.

 

On most projects, we talk about requirements or features that are either in scope or out of scope. But to effectively manage those requirements, we also need to prioritize them and this is where the MoSCoW technique comes in.

 

It classifies the importance of the different characteristics of a product in 4 Categories. M, S, C, and W:

 

• M is a must have requirement. Something that is essential and critical to the project and is not negotiable.
• S is a should have requirement. Something we need in the project if at all or wherever possible.
• C stands for could have. Something that is nice to have in case we have extra resources like time and budget
• W is a will not have requirement. Something that is out of scope for at least this time around

The Business Analysist can make use of any prioritization techniques to prioritize the requirements thoroughly. However, MoSCoW technique is an effective one to use among all the other prioritization techniques that are available. 

 

Some of the key benefits of using MoSCoW technique are listed below :

• Defines the project scope
• Saves time
• Plans the project deliverables
• Prioritizes the requirement
• Manages resources and requirements 

 

Illustration 1 :Take a human body as an hypothetic example. We will plot the 4 prioritization categories:

Must– a heart in the human body is “must”. Without it, there is no live organism. 
Should– a hand in human body is “should”. Without it is difficult. But one can survive even without hand. Well, if not in all, in most cases.
Could– hair in human body is “could”. It is okay to have them, you even look nicer, but in its absence, one can definitely survive
Won’t – unnecessary or not relevant in human body like waste. Probably, it might be an appendix

 

Illustration 2: MoSCoW example on a sprint project : Prioritizing Product Backlog 

The Product Owner (PO) is responsible for getting the Product Backlog ready and prioritizing the items in the Product Backlog. Prioritization is vital in any form of development work because choosing the right thing to do allows you to maximize the value delivered in a Sprint. The Product Backlog items should be ordered and sequenced in a manner that the requirements with maximum business value would be completed first and empowers a team to move in a uniform direction towards a common goal.

 

When doing the prioritization of your product backlog items at the Sprint planning session, here is a list criteria to be considered for your decision making:

• High customer value
• High benefit to the business
• Easy to be implemented
• High risk
• High cost if that is not implemented as soon as possible
• Dependencies between items
• Contribute most to the next Sprint goal?

Inference:
MoSCoW technique not just helps to prioritize the requirements at a high level, but also helps in specifying the detailed requirements, or features, of a product which enables you to delegate tasks better to team members and to set the expectations. 

 

MoSCow abbreviation is expanded as -

1.       Must Have

2.       Should have

3.       Could have

4.       Won’t have this time

 

Dynamic system design or Agile project, which needs to be delivered in a fixed time, methodologies like MoSCoW helps with a framework to rationalize prioritization and align stakeholder’s expectations.

 

The conventional prioritization approaches, i.e. Prioritization based on requirements being high, medium and low or a simple sequential tagging of requirements as 1,2,3,4… do not provide key stakeholders a very clear outlook on what to expect. The focused use of MoSCoW provides very clear visibility for key stakeholders on what to expect following the completion of a sprint (in agile methodology) or within a specific timeframe

MoSCow rules elaborated further –

 

a)      Must Have- These requirements are the MUST have requirements which the project/sprint guarantees to deliver. To categorize a requirement as must have, the requirement should try and meet the below criteria –

i) The product/service will not work in absence of this requirement

ii) it is unsafe or not legal to launch the product or service without these requirements iii) Solution is not viable without including the said requirement

 

b)      Should Have - These requirements are not vital, however are important. Exclusion of these requirements will be painful, but the solution will still be viable to meet expectation. These requirements would usually have some workarounds, and the key differentiator between “Should have” requirements vs “Could have” requirement is to assess the pain caused by not meeting the requirement, i.e. number of users effected, pain to perform the work around etc.

 

c)       Could have – These requirements are desirable, but less important to the overall solution and the impact is limited if left out, when comparing with “should have” requirements. Could have requirements can be considered in the main pool of contingency, and if the project timeliness are at risk, one or more of these requirements can be dropped with limited or no impact to the overall project

 

d)      Won’t have this time – These requirements are classified as the requirements which will not be met with the current timeframe of the project. Nevertheless, these requirements gets documented to avoid any scope creep eventually. Project team and stakeholders both agree on these requirements not being prioritized within a certain time, as the focus will remain on completing the must have and should have requirements

 

In summary, it is advised to not have anything more than 60% of the requirements as “must have” and 20% the requirements under “could have”. The change in this balance will pose a significant risk to the overall timelines of the project, and only exceptions to this will be in scenarios where the environment and technology is well understood and the project team is well established to accommodate such requirements.

 

 

Example – Most of the organizations are tacking the new migration of IE to Microsoft edge. Microsoft has announced that the earlier version of IE will not be supported after July, and all users should effectively migrate to the new browser. Some of the legacy business applications have IE as their default browser and changes needs to be made to the system architecture and connected applications to ensure MS Edge supports the day to day business operations.

 

Applying MoSCow, below are the critical requirements that the project team can prioritize –

a)      Must Have –

1. Integration testing with all business critical applications using IE as default browser
2. Test plan and outcomes of both IT managed and Business managed applications
3. Functional testing and synergy with all business critical applications

b)      Should have

1.  Integration and functional testing of internal applications (HR and Payroll etc.)
2. Integration and functional testing of internal Sharepoint used to track and monitor internal IT requests

c)       Could have –

1. Integration and functional testing with other ancillary platforms, i.e. internal reward and recognition website etc.  

d)      Won’t have this time

1. UI and Design testing for any of internal applications, i.e. existing HTML code compatibility testing with MS Edge

 

Most of the projects fail due to inadequate delivery with quality issues or excessive delivery with over shot time and budget . This primarily happens due to lack of prioritization in a very basic level . Most often it’s a misnomer that one tends to overdo in project assuming that customers need it but it would not be the case always . It is better to define customer requirement by using MoSCoW technique

First let us understand what these alphabets stand for

• Must have is denoted by - M which is essential and a prerequisite for the project and its not negotiable and it’s a must have type of requirement
• Should have is denoted by – S  which means we need it in the project if at all possible but not mandatory  
• Could have is denoted by – C  which is nice to have kind of scenario if we have the time and budget that permits it
• Wont have is denoted by –W which completely out of scope  is which is completely out of the radar and scope and we do NOT need it at all this time
•  
• 

 

Example :-

 

Management has given instructions to the team for preparing a Press Kit for the Press conference and the Project Head has given the requirements and the same has been split by using MoSCoW thechnique and the Press kit is prepared .

 

 

 

In Business  Analytics  MoSCoW when used will give following benefits   

 

MoSCoW is the method significantly used to help the stakeholders to understand the significance of the initiatives. MosCow Technique gives us the more granular view of the scope of the project and helps to deliver the most important feature to the customer first. It helps to manage to client expectation. It also helps to delegate work and to be clearly shows what is our high priority.

 

It’s a great way to frame the conversation with the clients, stakeholders to understand the ‘Must have’ and ‘good to have’ initiatives.

MosCow stands for a four category:

 

Must Have	Should Have	Could have	Won’t have
Non – Negotiable needs that are mandatory to the customers	Important initiative’s that are not vital and have significant Value	Good to have initiatives that have a small impact	Not a priority for this time frame to deliver

 

 Must Have: like Requirements, Critical features, No changeovers, to be done with the current delivery time box;

 Should Have: like important features, desired features, Valued to customer, can substitute to other feature but not with the current delivery time box;

 Could Have: like user improvement projects; sometimes valued, not necessary, with alternative we can deliver.

 Won’t Have: like least important, not appropriate one, not much worth, not appropriate for the current delivery

 

 Everybody are following MosCow method with or without our knowledge in our daily routine. We have planned lot of work to be completed per day or week.  But we will not have enough time to complete all the task in a week. Here comes the prioritization. First we need to list out all the task and start the prioritization of the work.

 

 All Agile projects are using the Prioritization. Product Manager prioritize the features and delivery team prioritize that accordingly and deliver the stories on each sprint. Usually the last sprint will make use of improvement or good to have requirements.

 

 Usually startups are using advance prioritization techniques. Which consist of set of rules and framework that results the good decision-making.

Prioritization often determines the success of the company.

Every delivery has a timeline and requirements and most of the project’s timeline is fixed, so that the focus must be on the most important requirements, and to understand and prioritize those requirements MoSCoW technique/tool is used. It’s prioritization technique/tool utilized in management, project management, and software development to succeed in a standard understanding with stakeholders on the delivery requirement.

 

What is MoSCow?

The term MoSCoW stands for

M - Must have

S - Should have

C - Could have

W - Won't have

 

In simple term prioritization categories has value in getting customers to better understand the impact of setting a priority, compared to alternatives like High, Medium and Low.

 

All requirements are important, but they are prioritized based on the delivery which gives most business benefit. In the delivery of any project will initially try to deliver all the Must have, Should have, and Could have requirements. If the delivery timeline does not permit all these then Should and Could requirements will be the first to be removed.

 

Must Have:

These are the requirement which is critical and without any one of these requirements, the project delivery should be considered as a failure. MUST is itself stands for Minimum Usable Subset of requirement.

Must have can be defined by questioning “What happens if this requirement is not met? And if the answer is project cancel then there is no point in excluding this from the prioritization list of requirements and it’s considered as Must have requirement.

 

Should Have:

These are the requirements that are important but not vital for delivery in the current timeframe. Should have requirements are as important as Must have, but they are often not as time-critical.

 

Could Have:

These are the requirements that are nice to have, which means if these requirements are not there then there is no impact on delivery, but if it’s there then customer satisfaction is high. We can include when there is enough time and resources available for delivery.

 

Won’t have (this time):

These are the requirements that are least-critical or out of scope or lowest beneficial or not appropriate at the time. Won’t have requirements are not planned into the schedule for delivery, we can either dropped or reconsidered these requirements later.

 

Below is example of MoSCoW technique:

 

You are going to buy a new car with 7 seater to travel with family on the weekends. The car should have reverse parking sensor and camera and fuel type CNG. And Favorite color is Blue, so you want to have a Blue color body

It would be also nice to have 7 inch Display Screen and Bluetooth connectivity for your iPod. In addition, you are fond of having a reverse parking sensor and camera.

Let’s define prioritization:

M – a new car for traveling, with 7 seats.

S – reverse parking sensor and camera, fuel type CNG.

C – a Blue color body.

W – 7-inch Display and Bluetooth connectivity.

 

 

 

MoSCoW is a tool for prioritization of your projects to make the business understand the products requirements. IT will be very much crucial for the stakeholders when they need to understand the features in a specific release.

MoSCoW  has four different categories:

• must-haves
•  should-haves
• could-haves
• will not have. “W” in MoSCoW is used to stand for “wish/delighters” instead of “will not have right now.”

 

Dai Clegg, software development expert,, created the MoSCoW method when he was working in orace and was  later added to Dynamic Systems Development Method (DSDM).

 

For example: MoSCoW can be applied to any product development - for example a food  app like Swiggy

• Must have - user should be able to order and restaurants should be added to add their food options
• Should have - Multiple options to add different locations and different orders at sametime
• COuld Have - recommend the restaurants with lower price
• wil not have - option to auto order breakfast & lunch scheduler based on scheduling for a month 

 

 

MoSCOW is prioritization technic for managing requirement and to help key stakeholder understand the signification for initiative/Projects in each phase or release.

 

MoSCoW stands for four different categories of initiatives:

• must-haves,
• should-haves,
• could-haves,
• will not have.

 

Below are the steps how planning is done based on 4 different categories and Prioritization is done.

 

Must-have initiatives :- As the name suggest these as must have things for any initiatives, it is non negotiation needs of any project or initiative.

E.g. Safety parameters of Airlines industry, Medical equipment ,etc.

Should-have initiatives :- These are just step below Must have initiatives, they are essential to the project but not vital. They basically add added significant value to the project or initiative.  Eg. Productive improvement , fixing minor bugs or adding additional features or functionality which will assist the project or initiative but without them still project with work.

Could-have initiatives:- These can be categories are nice to have things in the project or initiatives and it has very less impact to project if not done compared to Should have Initiatives.  Eg. Formatting updates and value added services apart from core task.

Will not have (this time) :- Here basically initiatives which can be work up in next phase of the project can be added which are very low priority in the project scope of current phase.

 E.g. Scaling the project for next cross department, launching products in other cities or  things part of phase 2 any initiatives.

MoSCoW Method for Prioritization :- With the categorization of task based on priorities  is an effective method for teams who would like to include stakeholders from the whole organization in their process and Capture a broader perspective by including participants from various functional departments.

A very clear categorization helps in making stakeholder understand how much effort goes into each category of any initiative or projects.

 

It is similar to TOC methodology of priorities 1st constrain area ( Mush have) and then work on non-constraint part in the initiates & just like in Hoshi methodology to prioritization on one or two break out KPI for any initiatives or projects ( Must have KPI).

 

The Moscow method is a technique used for prioritization in business analysis, Project management, and software development to be able to reach a common understanding of the stakeholders on the importance of each requirement for the delivery. This is also known as MoSCoW analysis or MoSCoW prioritization.

It helps the teams to manage their time & effort. This technique classifies the importance of different characteristics of a Project or product according to their importance.

The name itself is an acronym of the 4 categories of Prioritization (adding two ‘o’)

·       Must have – Essential Requirements. Critical features with no replacements

·       Should have – Important & designed Requirements. These can be substituted if necessary

·       Could have – Improvements in Project or product. There can be different alternatives to these

·       Won’t have – Characteristics which are agreed as not to be adopted hence no one should waste time in implementing them

 

 

Example of a project for Website Development:

Scope: Website Development for a Law firm

Requirement: A professional site where people can visit & register. Once they enter, they can even track their ongoing court cases

How to Follow MoSCoW Method:

Must have:

·       Strong program code without any bugs

·       Proper Register System

·       A safe & reliable personal directory ensuring customer’s privacy

Should Have:

·       Fast Speed

·       A good Design & aesthetics

·       Feature of Notifications via email

 

Could have:

·       Customized Menu option

·       Suggestions box

·       Blog section with latest news, posts or updates

 

Won’t have:

·       Any paid content

·       Public members view / section

·       Advertisements

 

Why is MoSCoW Method important:

·       Saves Professional’s effort & time on useless tasks that might be unwanted by the customer

·       Hours spent in modifications of features which might not be important for customer or missing an important thing

·       Concentrates the team’s effort and forces them to focus on what is important

MOSCOW Method from Prioritization

In a project where timelines are fixed, it is important to understand the relative importance of the work to be done for making progress and keep up to deadlines. Prioritisation can be applied to requirements and tasks

MoSCoW is a technique used for prioritising and for helping to understand and manage priorities and the letters stand for

• Must Have
• Should Have
• Could Have
• Won’t Have this time

In comparison to simpler prioritisation approaches which are primarily based on relative priorities, the MoSCoW method works betters as the use of a high, medium or low classification is weaker as their operational definitions are incomplete or missing.

The specific use of Must Have, Should Have, Could Have or Won’t Have helps in providing a clear indication about the item and the expectations for its completion.
 

MoSCoW Method - Detailed

Must Have

Must Haves list the Minimum Usable SubseT (MUST) of requirements which the project will deliver. The key question asked is if the requirement is not met, does it cancel the project.  If the answer is in affirmation, then it is a Must have requirement.

Should Have

Should Have requirements are defined as the ones that are important but not vital and can be left out even though the solution is viable which may need a workaround.
 

Could Have

Could Have requirements are the ones that are wanted or desired but is less important and has minimal effect if it is left out. These are the contingency items that would have be delivered only in the case of a best case scenario and can be avoided if there is risk to timelines.

Won’t Have

These are requirements which the team agrees that it will not be delivered during the timeframe. They are kept as part of the Prioritised Requirements List and help in providing clarity on the scope of the project

 

Example:

In case of an IT solution requirement for archiving old data, if Must Have requirement is that the solution should be sustained and used for a certain number of months without the basic facility being in place, it is better to categorize the requirement as a Should Have or Could Have for the initial project increment delivery time and ensure that later it becomes Must Have before the end of the project.

To concise, the project teams should keep the end product/deliverable in mind while categorizing the requirements and if following Agile methodology the categorisation should be at Timebox level.

To summarize, MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) is used to prioritise requirements, primarily, although it is also useful in many other areas. On a typical project, it is recommended that no more than 60% effort should be put in for Must Have requirements , and around 20% effort for Could Haves.

 

The selection of the winning answer was difficult this time. Everyone has correctly explained MoSCoW and given very interesting examples (these interesting examples make every answer worth reading once).

 

The winning answer has been provided by Pushpa S. Bharadwaj for additionally highlighting the limitations and overlap with Kano Model.