This technique is commonly used to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement
MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus can be on the most important requirements (the two ‘o’s are there just to make the acronym work)
Must have
Requirements labeled as MUST have to be included in the current delivery timebox in order for it to be a success. If even one MUST requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from MUST, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered as Minimum Usable SubseT.
Should have
SHOULD requirements are also critical to the success of the project, but are not necessary for delivery in the current delivery timebox. SHOULD requirements are as important as MUST, although SHOULD requirements are often not as time-critical or have workarounds, allowing another way of satisfying the requirement, so can be held back until a future delivery timebox.
Could have
Requirements labeled as COULD are less critical and often seen as nice to have. A few easily satisfied COULD requirements in a delivery can increase customer satisfaction for little development cost.
Won't have (but Would like)
WON'T requirements are either the least-critical, lowest-payback items, or not appropriate at that time. As a result, WON'T requirements are not planned into the schedule for the delivery timebox. WON'T requirements are either dropped or reconsidered for inclusion in later timeboxes. This however doesn't make them any less important.
Sometimes this is described simply as "Would like to have" in the future, this however leaves some ambiguity in the minds of the users as to its priority compared to the other marks.
This technique is good to be used during the release planning so that the entire team will be getting to know what is expected of them. Also this technique is an iterative and ongoing one.
If new "Must Have" requirements discovered during project then we need to renegotiate scope i.e. transfer equivalent effort of Should and Could Haves to Won’t Haves and renegotiate what are now Must Haves to maintain agreed percentage of effort for remaining time
And If it becomes clear that all agreed "Must Haves" cannot be completed then immediately STOP THE TIMEBOX then Re-estimate, Re-negotiate and Re-schedule the time and scope. Also make sure that you will never extend a timebox in order to achieve the Must Haves. Because time and budget are fixed, the only remaining variables are the requirements. So if a project is running out of time or money the requirements with the lowest priority are omitted. This does not mean that an unfinished product is delivered, because of the Pareto principle that 80% of the project comes from 20% of the system requirements, so as long as those most important 20% of requirements are implemented into the system, the system therefore meets the business needs and that no system is built perfectly in the first try.
MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus can be on the most important requirements (the two ‘o’s are there just to make the acronym work)
Must have
Requirements labeled as MUST have to be included in the current delivery timebox in order for it to be a success. If even one MUST requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from MUST, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important). MUST can also be considered as Minimum Usable SubseT.
Should have
SHOULD requirements are also critical to the success of the project, but are not necessary for delivery in the current delivery timebox. SHOULD requirements are as important as MUST, although SHOULD requirements are often not as time-critical or have workarounds, allowing another way of satisfying the requirement, so can be held back until a future delivery timebox.
Could have
Requirements labeled as COULD are less critical and often seen as nice to have. A few easily satisfied COULD requirements in a delivery can increase customer satisfaction for little development cost.
Won't have (but Would like)
WON'T requirements are either the least-critical, lowest-payback items, or not appropriate at that time. As a result, WON'T requirements are not planned into the schedule for the delivery timebox. WON'T requirements are either dropped or reconsidered for inclusion in later timeboxes. This however doesn't make them any less important.
Sometimes this is described simply as "Would like to have" in the future, this however leaves some ambiguity in the minds of the users as to its priority compared to the other marks.
This technique is good to be used during the release planning so that the entire team will be getting to know what is expected of them. Also this technique is an iterative and ongoing one.
If new "Must Have" requirements discovered during project then we need to renegotiate scope i.e. transfer equivalent effort of Should and Could Haves to Won’t Haves and renegotiate what are now Must Haves to maintain agreed percentage of effort for remaining time
And If it becomes clear that all agreed "Must Haves" cannot be completed then immediately STOP THE TIMEBOX then Re-estimate, Re-negotiate and Re-schedule the time and scope. Also make sure that you will never extend a timebox in order to achieve the Must Haves. Because time and budget are fixed, the only remaining variables are the requirements. So if a project is running out of time or money the requirements with the lowest priority are omitted. This does not mean that an unfinished product is delivered, because of the Pareto principle that 80% of the project comes from 20% of the system requirements, so as long as those most important 20% of requirements are implemented into the system, the system therefore meets the business needs and that no system is built perfectly in the first try.
