MoSCow prioritization technique plays a key role in Agile Project Management. In traditional projects, teams balance the ‘triple constraints’ of Scope, Time, and Cost. For Agile projects, however, the emphasis is on continuous value realization for the end customer. The triangle structure can be reused, but with a set of different vertices, namely – Value, Quality, and the triple constraints of cost, schedule, and scope. Value-Driven Delivery demands Value-Based Prioritization during Product Backlog refinement, release planning, and iteration/sprint planning. By doing prioritization the team aims to make a trade-off between the above constraints. Agile teams and business representatives work diligently to deliver the highest value to the customer as early as possible and at the lowest cost. This is achieved by consciously choosing the items or stories of the highest return on investment from the backlog and implementing the same in the available timebox.
Some of the factors that are considered to arrive at the priority of a work item are as follows:
- Business Value in terms of incremental or retained revenue and customer satisfaction
- Legal, regulatory and compliance requirements
- Cost of implementation and ongoing maintenance
- Urgency and time sensitivity of the feature in the product
- Early adopters for a niche concept in the market
- Greatest return on investment (e.g., quick wins) and likelihood of success in marketing the product.
- Inherent riskiness of the feature
- Stakeholder consensus
- Usability and reusability
- Amount of knowledge or experience gathered about the domain, technology, or the product
The MoSCoW prioritization technique has its origin in DSDM. DSDM(Dynamic System Development Method) is an Agile method that focuses on the full project lifecycle.
MoSCoW
It is an acronym that stands for
- M : Must have
- S : Should have
- Co : Could have
- W : Won’t have
Must Have
- Requirements that are fundamental for the working of the system. Hence they have the highest priority.
- If even one such requirement is excluded or not delivered, the system will fail or be rendered unusable.
- These requirements appear on top of the prioritized backlog and are most likely to make it to the backbone and walking skeleton of a release plan.
- The keyword MUST also can be used as an abbreviation for Minimum Usable Subset. This term is a close analogy of a minimally marketable feature (MMF).
- Example of a must-have feature for a mobile phone is the ability to make and receive calls and an address book to store the list of contacts.
Tips: Ask the question ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project – there is no point in implementing a solution that does not meet this requirement, then it is a Must-Have requirement. If there is some way around it, even if it is a manual and painful workaround, then it is a Should Have or a Could Have requirement. Categorizing a requirement as a Should Have or Could Have does not mean it won’t be delivered; simply that delivery is not guaranteed.
Should have
- Requirements that are important for the system to work correctly, reliably and predictably. Hence they have medium priority.
- If such a requirement is excluded or not delivered, the system can continue to function with a workaround that could either be difficult, time consuming, or cause inconvenience.
- Example of a should-have feature of a mobile phone is the ability to connect to a data network and being able to browse the Internet.
Tips: One way of differentiating a Should Have requirement from a Could Have is by reviewing the degree of pain caused by the requirement not being met, measured in terms of business value or numbers of people affected.
Could have
- Requirements that are somewhat useful or desirable, but not necessary.
- If such a requirement is excluded or not delivered, the system continues to function properly, but the user experience can be affected adversely.
- Their priorities are medium to low and are picked up for implementation provided there is sufficient time and money available.
- Example of could-have features of a mobile phone is to be able to play music, click photos, or help in GPS navigation.
Tips: These are the requirements that provide the main pool of contingency since they would only be delivered in their entirety in a best-case scenario. When a problem occurs and the deadline is at risk, one or more of the Could haves provide the first choice of what is to be dropped from this timeframe.
Won’t have
- Requirements that are cosmetic or ‘nice-to-have’, but are of least criticality.
- If such a requirement is excluded or not delivered, the system is not impacted in any way.Can be deferred for future or dropped forever.
- Example of won’t-have features of a mobile phone could be to act as pedometer
that counts steps for a morning jogger.
A requirement may have two priorities; MoSCoW for the project and MoSCoW for the Increment. At the time of planning a specific Timebox, the Developers will allocate a specific priority for the requirements for this Timebox. At this point, the majority of requirements are Won’t Have (for this Timebox). Only requirements that the developers plan to work on in the development timebox are allocated a Must Have, Should Have, or Could Have priority.
Therefore requirements may have three levels of priority:
MoSCoW for the project
MoSCoW for the Project Increment
MoSCoW for this Timebox
Example – Project: IT solution for building a data center for a software company.
Even if a Must Have requirement for an IT solution is the facility to archive old data, it is very likely that the solution could be used effectively for a few months without this facility is in place. In this case, it is sensible to make the archive facility a Should Have or a Could Have for the first Project Increment even though delivery of this facility is a Must Have before the end of the project. Similarly, a Must Have requirement for a Project Increment may be included as a Should Have or a Could Have (or a Won’t Have) for an early Timebox.
This MoSCoW technique is best used when the BA has gathered all existing solution requirements.
- Assemble all stakeholders – Each stakeholder, with help from the BA, is responsible for assigning priorities to the requirements that fall under their purview
- All Requirements may be listed on a flip chart and prioritized by assigning categories to each (M, S, C or W).
- If there are multiple stakeholders with different opinions on what category to assign to a requirement, voting can be used to reach consensus.
- Present categorized requirements in a readable format.
- The requirements should be reviewed throughout the project as stakeholder needs may evolve with time.
MoSCoW criteria
Eight criteria to be used for assigning priorities to requirements. They are:
- Business Value: Which requirement provides the most business value? The more business value a requirement will deliver, the greater the priority stakeholders may choose to assign to it.
- Business or Technical Risk: Some requirements pose a significant risk of project failure if not implemented successfully. The analyst may assign a high priority to this category of requirements so that if the project does fail, the least amount of effort would have been spent.
- Implementation Difficulty: Which requirements are the easiest to implement? Straightforward requirements may lead to quick-wins and provide an opportunity for the project team to familiarize themselves with other elements of the project before taking on more complex requirements for implementation.
- Likelihood of Success: Which requirements can provide quick-wins and increase the probability of project acceptance? If the objective of the project is to demonstrate value as quickly as possible and quell negative chatter, requirements that have a higher probability of success would be given high priority.
- Regulatory Compliance: Which requirements are necessary for policy and regulation adherence? These requirements are non-negotiable and usually have to be implemented within a set period of time, causing them to take precedence over stakeholder requirements in some cases.
- Relationship to other requirements: Which requirements support other high-value business requirements? Such requirements may be assigned a high priority because of their link to important requirements.
- Urgency: Which requirements have a high degree of urgency? Most stakeholders tend to place a high priority on requirements needed like yesterday
- Stakeholder Agreement: Requirements on which stakeholders disagree should be postponed or assigned a low priority until consensus can be reached on their usefulness.
Tips for Assigning Priorities – MoSCoW
- Ensure that the business roles, in particular the Business Visionary and the Business Analyst, are fully up to speed as to why and how DSDM prioritizes requirements.
- Consider starting with all requirements as Won’t Haves, and then justify why they need to be given a higher priority.
- For each requirement that is proposed as a Must Have, ask: ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project; there is no point in implementing a solution that does not meet this requirement’, then it really is a Must Have. If not, then decide whether it is Should Have or a Could Have (or even a Won’t Have this time)
- Ask: ‘if I come to you the night before Deployment and tell you there is a problem with a Must Have requirement and that we can’t deliver it – will you stop the Deployment?’ If the answer is ‘yes’ then this is a Must Have requirement. If not, decide whether it is Should Have or a Could Have.
- Is there a workaround, even if it is a manual one? If a workaround exists, then it is not a Must Have requirement. When determining whether this is a Should Have or a Could Have requirement, compare the cost of the workaround with the cost of delivering the requirement, including the cost of any associated delays and any additional cost to implement it later, rather than now.
- Ask why the requirement is needed – for this project and this Project Increment.
- Is this requirement dependent on any others being fulfilled? A Must Have cannot depend on the delivery of anything other than a Must Have because of the risk of a Should Have or Could Have not being delivered.
- Allow different priorities for acceptance criteria of a requirement.
- Can this requirement be decomposed? Is it necessary to deliver each of these elements to fulfill the requirement? Are the decomposed elements of the same priority as each other
- Tie the requirement to a project objective. If the objective is not a Must Have, then probably neither is the requirement relating to it.
- Does the priority change with time? For example, for an initial release a requirement is a Should Have, but it will become a Must Have for a later release.
- Prioritize testing, using MoSCoW.
- Use MoSCoW to prioritize your To Do list. It can be used for activities as well as requirements.
Table of Contents (PSM ™, PSPO ™ & PSD ™ Certification)
- Scrum Framework – Scrum Theory
- Scrum Framework – Scrum Roles
- Scrum Framework – Scrum Events
- Scrum Framework – Scrum Artifacts
- Scaling Scrum – DoD – DoR – Scrum Framework
- Developing People and Teams
- Managing Products with Agility
- Developing and Delivering Products Professionally
- Evolving the Agile Organization – Scaled Scrum, Portfolio Planning & EBM
Recommended Practice Exams
- Scrum.org
- Scrum Alliance
- PMI
Owner, PSPO, PSPO I, Scrum Open, etc. are the protected brand of Scrum.org. All the content related to Scrum Guide is taken from scrumguides.org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.