We work on a huge variety of digital projects, and we’ll often tailor our approach towards the kind of product being produced. That said, there are some steps we make sure we bake into every project, and possibly the most vital of these is the MoSCoW method.
The reason we do this is simple – development projects tend to come off the rails unless all stakeholders have agreed on a single, clear set of deliverables for each stage of a project, and the MoSCoW method is the best, most transparent way we’ve found of ensuring we get this.
What is the MoSCoW method?
At its core, the MoSCoW method is simply a prioritization framework that can be applied to any kind of situation or project, but it works best when a large number of tasks need to be ruthlessly whittled down into a prioritised and achievable to-do list.
The core aim of the process is to classify tasks (commonly called stories in the agile development parlance) into four buckets; Must, Should, Could and Won’t. As you can probably fathom, Must is the highest priority bucket, and Won’t is the lowest. You can also presumably now see where the funny capitalisation in the term ‘MoSCoW’ derives from.
Giving a project direction
One of the primary benefits of a MoSCoW exercise is that it forces hard decisions to be made regarding which direction a digital product project will take. Indeed, the process is usually the first time a client has been asked to really weigh up which functions are absolutely fundamental to the product (Must), which are merely important (Should) and which are just nice-to-haves (Could).
This can make the MoSCoW method challenging, but also incredibly rewarding. James Whitehouse, Joint Managing Director of Lightning API found the process particularly valuable, saying that their team “had so many ideas that we needed an external perspective to help us narrow our brief to an achievable MVP.” You can read more about the process we went through with Lightning API in our detailed case study.
How do you run a MoSCoW exercise?
It’s only really worth running a MoSCoW process once you feel you’ve got a full view of the project’s requirements. For us, this means we run the exercise at the end of the initial research and discovery phase that we encourage all our clients to go through. This is the point at which we’ve gathered all the information we can about the prospective digital product, including all the user needs, business objectives, technical requirements, UX goals and legal and regulatory specifications.
It’s not uncommon for there to be hundreds of user stories at this stage of a project, as they cover every aspect of what a user or admin will want to do with the digital product – everything from ‘As a customer, I can change my password’ to ‘As an admin, I can export transaction data as a .csv file’.
With so many stories to keep track of it helps to group them into sets. For example, you may want to group all the stories surrounding checkout, or onboarding into one group. We’ve found that this approach helps the flow on the day of the MoSCoW exercise, as it’s easier to debate everything about a discrete section of the product in one go than it is to jump backwards and forwards between login, checkout, stock admin and invoicing, for example.
Depending on the size of your project, you may also find specialist software useful for logging, classifying and organising your stories. We use JIRA, but there’s plenty of other project management platforms out there too.
Make it a physical process
One of the best aspects of the MoSCoW method is that it works well as a physical process, and this is an approach we’d encourage you to take.
It requires some prep work ahead of time (printing off and cutting our the stories), and you’ll need the space to carry out the process too, but we’ve always found that people remember the outcomes of the day better when it’s a physical process.
If you’re carrying out your MoSCoW in this way, you’ll need a mechanic to represent the four buckets that you’re putting the stories into. We’ve used self-adhesive magic whiteboard sheets before to good effect, but you could also use four small tables. We’ve even seen it done with washing line style buckets before, with stories attached to strings via clothes pegs. Whatever approach you take, it needs to be obvious at a glance where the biggest mass of stories is accumulating.
If you do carry out a physical MoSCoW, it’s absolutely crucial to take photos of each of the buckets in situ at the end of the exercise. Crucial! Take it from us, it’s embarrassing to go back to a client and have to explain that a colleague accidentally mixed up the story cards when cleaning up after the exercise…
Everybody needs to be in the room
Naturally, these processes work best when every stakeholder and stakeholder team is present, or at least represented in the room while these decisions are being made. This can make scheduling the exercise a herculean task, but you’ll benefit in the long run.
We’d also encourage you to make sure you have some technical talent in the room, such as the developers who may be building the product. They will often bring an alternative perspective to the proceedings, making technical links between stories that appear unrelated (‘ah, we can only do this, if we also do this, which makes them both a Must’).
Effective moderation is vital
With everything listed above in place, you’re ready to start the process of picking up the individual stories, reading them aloud to the group and then debating which bucket they should go into.
It’s at this point that the moderator becomes key. Each different group of stakeholders will bring their own set of biases or goals into the process, and you, as a moderator, need to do your best to keep the process on track.
For example, in our experience, clients can have a tendency to try and place every story and function into the Must bucket which, unless they’ve got the budget of a world superpower and a timeframe measured in years, is likely to be unworkable. Likewise, developers or technical stakeholders can sometimes focus exclusively on the time (in workdays) a story will take to complete, rather than it’s value to the product or customer.
In both circumstances (and others) it’s the job of the moderator to coax the stakeholders to an agreed position on each story. This isn’t always easy, but we have found that being clear about the meaning of each bucket at the start of the exercise helps.
When we run a MoSCoW process, we use the following definitions:
Must – These stories are vital to the function of the digital product. If any of these stories were removed or not completed, the product would not function. All of these stories will be included in a minimum viable product (MVP) build. For example, being able to log in.
Should – These stories make the product better in important ways, but are not vital to the function of the product. We would like to add these stories to the MVP build, but we’ll only start working on them once all the Must stories are complete. For example, being able to filter job listings by postcode.
Could – These stories would be nice to have, but do not add lots of extra value for users. These stories are often related to styling or ‘finessing’ a product. These stories will likely be added at some point in the future, but not at this first build stage.
Won’t – These stories or functions won’t be considered at this stage as they are either out of scope or do not add value. Note that these stories don’t simply get dumped. Rather, they can be used as a basis for a future product roadmap, to be worked on as a product progresses. For example, adding a premium car option to your taxi-hailing app.
By the end of the process, the group will have allocated all the stories to one of the four buckets, giving a complete overview of the priorities for the design and development process of the project.
What are the outcomes of a MoSCoW process?
The most important and obvious outcome from a MoSCoW process is a clear and shared sense of a project’s priorities and direction. Everyone involved in the process should now be agreed, more or less, on which stories or features will be developed first, once the project moves to the build stage.
Even more than that, it should now also be possible to see the outline of the MVP build of the product by looking at the stories in the Must and Should priority buckets.
Matching priorities to budget
At this stage, the bulk of the work has been done, but unless you’ve been absurdly lucky you’ll need to finesse your list of prioritised stories to fit your resource budget.
You can choose to do this however suits you and your project best, but the approach we’ve found to work for us is to attach budget estimates (time or pound value) to each user story. This allows us to ascertain how many of the Should stories we’ll need to leave out of the MVP build to hit the agreed project budget (remember, dropping any of the Must stories likely isn’t an option).
In an ideal world, your project budget will cover all the stories you’ve classified as Must and Should, but more likely than not you’ll find it only stretches to your Must stories, plus about 20-40% of your Should stories.
(If the budget doesn’t even cover your Must stories, you’ve got a problem and you and your stakeholders either need to rethink the budget or the scope of the project).
Here, we like to bring in the client and key stakeholders and engage in a kind of jigsaw puzzle process of fitting the Should stories to the remaining budget; would the client prefer that one big extra feature, or many small UX and UI tweaks that, added up, cost the same?
Naturally, this means another round of hard decisions, but on the plus side, you’re aided by the attached budget estimates this time, which can make it quicker and clearer what the impact of a decision is.
Don’t forget the Could and Won’t bucket
An additional (and often overlooked) outcome of the MoSCoW process is that it creates an almost ready-made feature roadmap for the product or digital platform in the shape of the stories that fell into the Could and Won’t buckets.
These stories likely won’t even be considered for the MVP build, as they have been classified as nice to have’s, rather than vital features. However, once the MVP product has been developed, hit the market and started generating revenue, normally a product owner will want to iterate on and improve their product.
This is precisely where these ‘nice to have’ product features and user stories can come in handy, so don’t throw them away or lose the images you took of these buckets. We’ve resurrected Could and Won’t buckets up to a year after an initial MoSCoW process took place as clients have decided to revisit features that there wasn’t either the time or resource to develop for the first iteration of the product.
Pitfalls to avoid
As with any process, there are a few things that can trip up a MoSCoW exercise.
The biggest issue is one I’ve already mentioned (though it really does bear repeating); care must be taken to ensure the definitions of the four priority buckets are clear and well defined from each other.
The root cause of most of the hiccups we’ve encountered when running MoSCoW method sessions has been confusion over the differences between the buckets. For example, what makes something a Should, rather than a Must, and will stories that go into the Won’t bucket just be forgotten?
Big personalities can dominate
Secondly, because MoSCoW is a group process, you need to be careful not to allow any one personality in the room to dominate. This can lead to a skewed priorities list and, in the most damaging cases, to a lack of buy-in from other stakeholders that were in the room.
The best guard against this is effective moderation, but you can also put some simple rules in place to make sure everyone gets their say. Our favourite is rotating the responsibility for reading out and giving the first opinion on the stories, as this pushes everyone in the room to speak and give their views in a structured way.
Timing is left open
A final, commonly cited criticism of the process is that it is relatively ambiguous about timings. It has little to say about when we will be getting these tasks or stories done, which can leave participants without a clear idea of what the next steps are.
Personally, I think this critique is a little unfair. Surely any project team worth their salt should be able to develop timings for the next steps of the project based on the outcomes of the exercise? Alternatively, if you feel you need to come out of the process with some sense of timings, it’s a simple task to build deadlines into the bucket definitions; work will start on Must stories this month, Won’t stories will be shelved until V2.0 is set to be released next year.
In summary
The MoSCoW method is a simple, flexible prioritisation technique available for digital project teams to use. We find it particularly useful deployed at the end of an early project research or discovery phase, and feedback from our clients tells us that it’s one of the project steps that they find most valuable.
Once you’ve completed your MoSCoW method workshop, you should emerge with an idea of what your digital product MVP build will look like, and what features and stories you’ll be adding to the product over the next year or so, once the MVP has hit the market.
The method isn’t perfect; it needs a good moderator to be most effective, and it has little to say about how quickly the prioritised stores should be completed. Even so, the MoSCoW method is still very powerful when deployed well. We certainly wouldn’t expect to run a project without one.
The post The power of the MoSCoW method appeared first on Browser London.
Top comments (1)
Hey, nice explanation here of the MoSCoW method to prioritize work to do.
I think many companies do some kind of prioritization but only in terms of important/less important stuff. MoSCoW opens the door to more effective way to order features to work on.