How to run a prioritization session using the MosCOW framework

December 19, 2019 - 8 minutes read - EN

The MoSCoW method is a prioritization framework.

It consists of four quadrants:

Must-Have
Should-Have
Could-Have
Won’t-have

These four quadrants classify requirements:

Must-Have: Those are required for the release to have the expected outcome. I often use the skeleton analogy of our bodies. Everything in this quadrant has proven value or is a vital element of the new product or feature. These requirements are also pre-requisite of others. We need to develop them first. MUST is also an acronym for Minimal Usable SubseT. Think also Minimally Viable Product (MVP).
Should-Have: Those are requirements that will have an impact on the new product/feature, but the product/feature can work without them. If you work in cycles, they can be part of the next cycle. You can start building these requirements once the Must-Haves are complete if times and resources permit it. They may have less clear value or depend on some Must-have.
Could-Have: These requirements are desirable. They will most certainly improve the product/feature but are not essential. Sometimes their value is not clear; sometimes we need more information: data, user feedback or user-research
Won’t-Have: Those are requirements you will not do for this product/feature for this cycle. Use this quadrant to define what the team has agreed not to do for this release. It is beneficial to document these agreements. Focus on the current cycle: aways changing the future is!

How to run a prioritization session with MoSCoW

The prerequisites are:

a team
a strong why
a product vision / shared problem space definition
a product-brief
If possible, a press-release (1-page max) to share with everyone what success looks like for this iteration.

If you are missing some of these critical elements, the risk is that the prioritization could be highly inefficient. While building this shared understanding (and producing the documents above), you should pre-fill the MoSCoW grid with what the team has already discussed. This

I used a simple visual code for each item in the grid:

Todo (agreed upon by the team and in the Must-Have quadrant)
- Team is aligned and this requirement is in the correct quadrant
? To be discussed (not agreed upon but captured during discussions or any social interaction)
🐽 Team disagreement / May need further discussions or stakeholder input
☑️ Done — This requirement has shipped

You can make your own or use the empty MoSCoW template and pre-fill it to the best of your knowledge.

Invite the team

Once you have done that, you are ready to invite the team to the session. If this is the first time you are using MoSCoW with this team, you can send the link to the Wikipedia article (or this blog post ;-).

Make sure to attach the MoSCoW matrix or share it in your favorite team communication tool before the meeting.

The meeting

Make everyone comfortable. Explain the process and why the team is in the room. Ask questions about MoSCoW and make sure to clarify the definitions. Make sure to specify the time-scope of the exercise: the next release. I also like to mention that nothing is permanent and that we can change these decisions at any time.

The value of the MoSCoW method comes from the super-interesting discussions it will generate. The talks are a forcing function to create team alignment rapidly. You will also identify the points of misalignment/indecision. These points will be visually easy to spot on the MoSCoW matrix with the proposed pig noses (🐽) symbols.

Depending on your current alignment, you can experiment with three types of meetings. I will propose two structured approaches and one unstructured approach that is more like a free-form conversation.

In my experience, the first few times I used the framework, I used a structured approach. These days, I tend to use a free-form approach, merely making sure we spend some time on each segment. Feel free to experiment with these approaches.

Weak alignment:You should start from the less absolute quadrants. Namely the could-have and should-have.

The proposed path will help the team to build their prioritization muscle.

The proposed path is illustrated on the left.

Could-Have: try to move things from this quadrant to won’t-have or should-have quadrant.
Should-have: idem but move requirements to the must-have / could-have quadrant.
Must-have: It is OK to spend time on this quadrant and have a deep discussion.
Make sure you capture all the requirements that will not be built for this release. This one is often easier.

Already a strong alignment.

If you already have a strong alignment the Must-Have and Won’t-Have quadrants should be well defined. Start with the already agreed upon points.

Must-Have: Start from there as the team alignment is built in this quadrant. Do not leave any requirement undiscussed but focus on the one with ? and 🐽. Build alignment on these or move them to another quadrant.
Won’t have: Should also be quite clear and fast. Don’t hesitate to move things around and clarify
Should-have: This is where you should spend most of the team time. Lots of interesting discussions to have. Discussions will mostly be around the should-have vs could-have requirements.
Could-have: If you have time, otherwise, you can move to the conclusion.

Free-form discussion

In this type of workshop, the flow is free. You can still use some form of prioritization: quadrant by quadrant.

You can prioritize based on the various requirement importance: start from the most pressing issues that the team has.

Another possibility is to go in turn. Each attendee picks one requirement they think is in the wrong quadrant, one in the right quadrant and one missing requirement. The last method guarantees the fair participation of everyone and is very remote-friendly.

The tricky thing is to make sure the team is spending enough time on each quadrant.

Tip: use the MoSCoW quadrant forcing functions

When a discussion derails, and we start bikeshedding or making plans to go to Mars, keep everyone focused on the goal/quadrants. You can use one of the following questions are a forcing function to make a decision and move to another subject:

Should we change this requirement from Must-Have to Should-Have?
Should we add a new requirement to capture this discussion? In which quadrant?
I think we disagree, let’s use a 🐽 for now, and move to the next quadrant/requirement/person. We will come back to it later.

10 minutes before the end: the quadrant walk-through

Revisit the Won’t-Have quadrant

Make sure to revisit the won’t-have quadrant. Lots of time, we moved things around, and we may have added new requirements. This white-space thinking is super-useful to define what we don’t want to build.

For instance, in one of the sessions, we had a generic no buyer facing interface requirement. During the discussion, we discovered that we now have a specific buyer facing element in our should-have quadrant. As a consequence, we changed the won’t have one to a more accurate no buyer facing interface — pre-checkout in the won’t have.

It is super-important to do that otherwise you will end up with some contradictory document and misaligned team.

Focus on the Must-Have

This quadrant represents the core of the product. Use leading questions like:

Are we ready (even if uncomfortable!) to sacrifice everything else to develop these requirements?
When all these requirements will be built, can we launch our product?
Is everything in the Must-Have column necessary?

These questions will generate interesting alignment discussions: some requirements will move to Should-have and some Should-have to Won’t-have.

The conclusion of the meeting is not a time for discussion: if the team disagree, use the pig nose symbol (🐽) and move forward to the next requirement.

The must-have quadrant should now be quite robust, as well as the won’t have quadrant.

If you are short in time, stop there and move to the conclusion of the meeting.

2 Minutes before the end: Conclude / Wrap-it up.

At this point, you will most certainly navigate between these two scenarios:

Alignment not built yet.

Some team disagreement (🐽) in the Must-Have and Won’t-Have quadrants are a manifestation of misalignment. Make sure you have follow-up action-items assigned to team members for which these requirements are essential. You can go 1:1 for these or use another session.

Strong alignment on essential things:

If you don’t have any disagreement in the Must-Have and Won’t-Have quadrants, congratulation! You have now a well-aligned team and a document ready to share.

It is perfectly OK to have some disagreements (🐽) in the Should-Have or Could-Have quadrants. Those are good candidates for some data-deep dive, user research or UX explorations. Try to find motivated team members to help the team understand better these requirements.

Conclusion

The MoSCoW matrix is super simple but quite powerful to generate valuable team-level discussion. The framework will guide your team discussions toward an agreed-upon prioritized requirement list.

After a few meetings (or one-on-one with key team members), you will reach alignment within your team. Congratulations!

You can now share the MoSCoW prioritized requirement list with your stakeholders. Use one of the methods exposed above when you discuss prioritization with your stakeholders:

Be open to new requirements: add them in any section with a “?” so that you can analyze this scope change with the team;
If some stakeholder disagree, use the (🐽)

This document is a live document: it should not remain untouched for months in a row. Every cycle, you should be able to mark things done (☑️), and once the Must-Have quadrant is completed: you can release your new product!

When you have almost completed all the requirements in your Must-have quadrant, you can then start a new cycle with the Should-Have as a good starting list for the must-have quadrant. You can then organize your next MoSCoW prioritization team session!

Questions:

Have you used this method before? Any tip to share with the audience?

Do you use another framework, how does it compare/relate to the MoSCoW one to build team and stakeholder alignment?