Prioritisation is hard. Thankfully, there are lots of simple ways of thinking through how important something is to the next version of a product or service. One of these ways is the MoSCoW method. However, we always forget to capitalise the correct letters in that acronym, so we just call it Must / Should / Could.
Using a Whimsical template, it’s really easy to get started with this approach. All you’re going to end up doing is:
- Decide on the scope or context of what you and your team are discussing
- Fill in some sticky notes about possible features / functionality for the next version of your product or service
- Drag these into the right place on your three-part Must / Should / Could template
Target group: project team, workshop group
Time: 20 – 30 minutes
Material: Whimsical template
Goals: visual overview of what’s most important in the next iteration of a product or service
The first thing to do, then is to decide what you’re going to be discussing. In this example, it’s v0.2 of an app that a team is working on. Next, just add all of the things that you’ve been contemplating adding to this version. It could be small things, or large things. It doesn’t really matter. If something is too big, though, you might want to break it down into smaller bits, or if it’s too small, you might combine it with something else.
From experience, we’d say that the trick here is to ensure that you’re specific enough with the stickies, without being overly-prescriptive. For example, “Add dark mode” is sufficient, without specifying the hex colours for all of the different elements!
Once you’ve got all of the candidate sticky notes on the Jamboard, it’s time to have a discussion about where everything should go. Note that if a sticky note doesn’t make it onto the Must / Should / Could area, then it’s a “Won’t Do” for this iteration. You can always come back to ideas for the next iteration.
There are many ways in which you can get the sticky notes onto the various areas:
- Full anarchist — anyone can grab a sticky and put it anywhere they like, and then you have a chat afterwards
- Turn-by-turn — everyone gets a turn and, on their go, either adds a sticky, or moves an existing one (if the latter, they have to explain why)
- Command-and-control — the team can make suggestions, but only the team leader decides where each sticky note goes
The value of this approach is that it gives a visual overview of what’s most important in the next iteration of a product or service. You can then create a prioritised backlog for development. The conversation that leads to the final version is important, as it helps with team buy-in.
Click here to make a copy of the Must / Should / Could template