MoSCoW method is a prioritisation technique that was created by Brian Wilson in the 90’s. The idea behind MoSCoW is to find out which features are more valuable for your users and inform them about that through product roadmaps.
MoSCoW stands for:
- M – Must have (deal breaker)
- S – Should have (would be nice)
- C – Could have (nice to have)
- W – Won’t have (not now, not ever).
The last two categories are often combined into one “wish list” category. If you’re just getting started with creating a roadmap this is the easiest method to use as it only requires numbering items 1-4 or 1-3. You could also use the MoSCoW method to prioritise ideas for new features by numbering them 1-4 or 1-3 with 1 being most valuable.
Admap, an international marketing magazine, wrote about this technique in their February edition with focus on software products. It’s a great read that also briefly explains MoSCoW usage.
You can download our free ebook on Digital Product Roadmapping using MoSCoW here . You’ll also get updates about future roadmaps and more interesting blog posts by entering your email address below.
If you’ve any questions regarding the roadmaps please contact me directly at [email protected] or leave us some feedback below. I would love to hear your opinion on the roadmaps. Cheers!
“By letting your team brainstorm ideas for features, you can prioritize them all with MoSCoW notation to help identify the most important priorities. Using the example above, the business could vote on which features are needed first by voting “must have now,” “should have sooner,” “could have later,” or “won’t have at all.” The product owner then weighs each idea using this criteria and decides which one to work on next.”
The Product Owner works closely with the Scrum Master and Stakeholders to ensure they are informed of new changes that may impact their ability to meet objectives. A Product Owner may be assigned to one or more Sprints, and while they cannot assign tasks within the Sprint, they can prioritize the backlog in order of importance. The Product Owner is accountable for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, teams, and individuals.
The Product Owner is one of three roles filled on a Scrum team which requires external interaction (the other two being functional managers and stakeholders). Typically, it will also be necessary for that person to interact with another role on an Agile development team: whatever role that might fill; often this is a Project Manager/Scrum Master, but it could also be any member(s) of any stakeholder group (such as Product Marketing, Legal, Sales).
The Product Owner is accountable for managing the Product Backlog to maximize the value of the product. This is done by ensuring that all Increments align with what’s most valuable to create and meet stakeholder needs. The Product Owner represents all stakeholders in this sense.
There are times where the Development Team will need clarification on requirements; i.e., it should be clear to both parties what “done” means in regards to what has been built (see Definition of Done).
Additionally, there are disputes that may arise between other roles or individuals outside of Agile teams (e.g., managers, users, etc.). If these happen, the Scrum Master handles them; however, the Product Owner’s responsibility is to make clear how they will resolve such disputes.
It is important for the Development Team to understand that their focus should be on delivering the product by maintaining a steady pace, which helps keep momentum and morale high. So long as everyone agrees to what tasks are being worked on, what “done” means in terms of reaching this agreement, and each team member stays focused on working towards these goals, then there should be no need for other roles or individuals outside of this Agile team (e.g., managers, users) to step-in. This would only interrupt the flow.
An example where another role may step-in could be if a user requests an enhancement that doesn’t align with what was previously committed. Assuming this request is received in enough time before the deadline, the Product Owner could ensure that it is still included and then communicate with the Agile team to determine a plan for handling any additional work. This can be done by making users aware of what was previously discussed or agreed upon, while at the same time letting them know that they will need to prioritize which tasks are required to meet their goals for this release.
The MoSCoW method for creating a product roadmap is a decision-making tool that allows Product Owners and stakeholders to prioritize features based on four different desires: Must, Should, Could and Won’t. This model is useful for mapping out an initial product roadmap while at the same time ensuring that resources are being allocated effectively.
The MoSCoW method works well for Agile teams because it gives each user a voice when prioritizing which items should be included in a release. In order to apply this model from an organizational standpoint, Product Owners must ensure their users have been trained so they understand what each label means. The labels themselves can just be a starting point for discussion but the important thing is to ensure all stakeholders are talking about these issues together.
