Prioritization played a significant role in the success of most feature-rich apps, such as Slack and GitLab. Initially, they offered a limited set of functionalities that were essential for their users. With time, this set was supplemented with other features. Railsware is going to share its own style of prioritizing and show you how we use the MoSCoW method to get long lists of tasks done.
Why do you need prioritization?
As a rule, the daily routine includes a bunch of tasks. Ideally, you’ll have enough time and energy to cover all of them – but it just might happen that the number of tasks is immense and the resources available are not in abundance. That’s where prioritization comes in.
This term denotes a process to filter what you have to do in order of importance or relevance. For example, if you’re building a house, you are not likely to begin with the roof or walls until your foundation is done. Of course, things are much more complicated in the web development industry, and this example cannot reveal the full-scope value of setting priorities.
Complex projects and numerous startups make use of advanced prioritization techniques. These usually consist of frameworks known for specific requirements or rules that improve decision-making. Success in prioritization often determines the success of the company itself. Getting caught up in pending and undone tasks is a straight road to failure. That’s why businesses pay particular attention to which prioritization methods to use. There are quite a few of them, but they all have some common characteristics, such as orientation towards input (internal or external) and quantitative or qualitative tools.
External orientation means that you need to involve stakeholders outside the development team to set priorities, while the internally-oriented methods can be executed purely in-house. Quantitative methods entail a deeper focus on numeric metrics in prioritization, and the qualitative one rests on expert opinions, votings, classifications to a greater extent. In view of this, they are traditionally divided into the following categories:
You can read about different Agile prioritization techniques in detail here.
Railsware prefers a technique developed by Dai Clegg way back in 1994. Initially, it was named MSCW, but two o’s were added to improve pronounceability. This also made it sound like the capital city of Russia. Let’s see how it works.
What is MoSCoW?
To understand the gist of the MoSCoW method, we need to look at its origin – the dynamic systems development method (DSDM). It is a framework for Agile project management tailored by practitioners with the aim of improving quality in rapid app development (RAD) processes. A hallmark of DSDM projects is strictly determined quality, costs, and time at an early stage. In view of this, all the project tasks have to be allocated by importance. The need for managing priorities triggered the invention of a specialized prioritization mechanism.
This mechanism was implemented via MoSCoW – a simple yet powerful solution to set priorities both with and without timeboxes. However, it shows better efficiency if you have a certain deadline for a task, feature, subfeature, functionality, etc. The framework is applicable to all levels of project prioritization from top to bottom, as well as to all functions and focus areas.
The MoSCoW abbreviation (except for the o’s) is carved with first letters of the priority categories it works with. These are Must-haves, Should-haves, Could-haves and Won’t-haves. And that’s how you can define which task falls into which category.
Prioritization rules
These rules or requirements estimate the importance of any task/process/feature/etc. Each company or work team uses its own approach to setting requirements, but, in general, they do not differentiate much and look as follows.
Must-haves
These are top-priority requirements, which shape the foundation of the major pipeline. Avoiding them means blocking the entire project or further activities. As a rule, product ideation depends entirely on defining must-haves using such pointers as ‘required for launch’, ‘required for safety’, ‘required for validation’, ‘required to deliver a viable solution’, etc.
- Can we move forward with the project if this task is undone? – if NO, it’s MUST.
Should-haves
This type of requirement is of secondary priority. Should-haves do not affect the launch and, traditionally, are considered important but not crucial. They differ from must-haves by the availability of a workaround. Therefore, the failure of a should-have task is unlikely to cause the failure of the entire project. If you’re building a product, it will still be usable even if these requirements aren’t met.
- Will we move forward with the project if this task is done a bit later? – if YES, it SHOULD.
Could-haves
The next requirement is less important than the two previous ones but still wanted. If we compare could-haves with should-haves, the former is defined by a lower degree of adverse effect if omitted. Traditionally, the third-level priority requirements in the Agile framework MoSCoW are realized if a project is not highly constrained in time. Within the product development, we can call them low-cost tweaks.
- Can we sacrifice this task till the deadline? – if YES, it’s COULD.
Won’t-haves
You can also encounter this type of requirement under the name of would-have or wish-to-have, but these variants are not recognized by the Wiki. However, regardless of the chosen name, these requirements define the lowest priority for tasks that are unviable to implement with a particular budget and deadline. Won’t-have does not mean a complete rejection of something. It envisions reintroduction under favorable conditions in the future.
- Can we get back to it when things are going better? – if YES, it’s WON’T.
In search of the perfect tools and techniques, our team often modifies some well-known approaches and tailors them to our needs. This constant search and improvement led us to brand new product ideation and decision-making framework: BRIDGeS. BRIDGeS is a flexible approach for multi-context analysis suitable for building effective product strategies, solving operational and strategic problems, making day-to-day decisions, and more. Find out how to use BRIDGeS and what advantages BRIDGeS can bring to your team.
MoSCoW is another tool that we modified to make it even more flexible and versatile. Below, we share our findings to help your team nail prioritization in a more efficient way.
How the Railsware team modified MoSCoW
The main difference between the classical MoSCoW and our version of this technique is that we added another level of prioritization within such groups as Must, Should, and Could. Each of these groups of requirements got another 4 complexity categories:
3 – most heavy and unclear requirements
2 – heavy complexity
1 – normal complexity
0 – easiest and the most urgent tasks within the group
This way, when a requirement gets, let’s say, the priority Must, we can also add a numeric matter to the letter M. For instance, our sprint can include several M2 tasks, one M1 task, and three S1 tasks.
When the task is marked with the priority “3” (M3/S3/C3), it most likely means that its scope is too large and complex to be fulfilled fast. You need to decompose it into smaller, manageable chunks and prioritize them as well. This way, from one M3 requirement, you can get a bunch of M2, S1, and C1 tasks, for example.
Sometimes, M, S, C, and W letters are not enough and we may also need an Urgent Must (UM) mark. UMs are the most critical things, such as hotfixes, bug fixes, and patches, which block the work of the whole team. From our experience, we recommend you to fix these tasks ASAP, as they hinder the team’s productive work. So if you set any task as UM, you should ignore all other tasks until the UM task is fixed. In normal situations, your bug tracking system shouldn’t have UMs.
Why do Urgent Must tasks appear? Often, UMs are the Must-haves that your team ignored before the deployment phase or missed during the QA phase. Pay attention to these tricky cases, and try to solve them before they become an obstacle.
Advantages of the modified MoSCoW approach
When we got an additional level of priorities within the MoSCoW system, we felt the following improvements:
No need to run several rounds of task prioritization. When you have six Must-have requirements, you can’t understand which of them are the most critical or complex and run another round of prioritization. Our approach allows us to set priorities and clearly understand the importance and complexity of each task from the first round.
Saved time. The ability to set all priorities at once saves time for all the team members who take part in the prioritization process.
More balanced sprints. A sprint that consists only of Must-have tasks has little chance of being fulfilled. Must-haves are usually more complex requirements that guarantee the viability of a product, meaning their implementation takes more time and concentration from a developer. To dilute high-importance work with some low-hanging tasks, you can add some S0, C0, or S1 tasks to the sprint so that users get a bit more full-featured functionality of the main Must-have flows.
More pleasant products for end users. While M3 and M2 tasks are usually crucial things necessary for the product viability, Could- and Should-haves may represent more pleasant things (changing a theme, additional filters, notifications, etc.)
How to use MoSCoW
Everything looks simple in theory, but is it in practice? Let’s check out how a traditional MoSCoW analysis of functionality prioritizing works through the example of a regular web application. As a sample, we’re going to use basic functions taken from one of the Railsware products.
List all tasks
Prioritize cards
Based on particular requirements for budget and time, we can single out the most fundamental features to be implemented in the minimum viable product. After the priority analysis, we’ve got the following:
A user MUST sign up.
A user MUST log in.
A user MUST reset password.
A user MUST open a time-tracking page.
The top-priority tasks are followed by important, though not vital,functionalities for the app. These are:
A user SHOULD choose the billing system.
A user SHOULD delete an account.
A user SHOULD choose time-tracking options.
The evolution of the app does foresee its availability on mobile devices. However, this task is only nice-to-have at this point.
- A user COULD install a mobile app version.
And now the least-priority feature. It aims at enhancing the user experience once the app is on track. Theme selectability is definitely not what we’re going to make now, so this feature is saved for later.
- A user WON’T choose the app’s visual theme THIS TIME.
Restructure cards according to their priority
This step allows you to see the quantitative ratio of high and low priority tasks.
The most difficult thing about prioritization is to be icily intelligent and focus on the essential tasks to be done. Otherwise, you can get into the EVERYTHING-IS-MUST trap, according to which any feature like the billing system option or mobile app availability turns into the must-have.
And that’s why the MoSCoW Agile method is cool. It allows you to define a basic feature set, which has top priority and emphasizes that you do not need to abandon anything. The healthy balance of must-haves + should-haves is 50% of the entire scope. All (or almost all) of the tasks will be implemented later but in the order of their importance to your goal. The goal of this example is to build an MVP, and the categorization above shows the expected progress of the app’s functionality.
How to use modified MoSCoW
We took the same example with all the tasks listed above to showcase how we apply our version of this prioritization technique.
Set priorities using the extended MoSCoW model
The main priority (Must, Should, Could, and Won’t) are still the same, however, we dived deeper to make a more precise priority estimation of each task. Here’s what we came up with:
“A user can sign up” got an M2 mark. It is a complex task, but it’s not critically urgent.
“A user can log in” got an M1 mark. The task is important but not that complex.
“A user can reset password” got an M1 mark.
“A user can choose the billing system” got an S3 mark. It’s an important feature, but its scope is large and should be split.
“A user can delete the account” got an S2 mark.
“A user can open a time-tracking page” got an M2 mark.
“A user can choose time-tracking options” got an S1 mark. This is a low-hanging feature that can be taken to a sprint to balance the workload.
“A user can install a mobile app version” got a C3 mark. This epic is too large to be implemented in one sprint. Its scope should be split into smaller tasks and prioritized as well.
“A user can choose the app’s visual theme” got the same priority mark – Won’t, which we do not decompose.
Our modified approach provides a better understanding of the task’s priority and complexity and shows the parts that need to be reconsidered. This way, it’s easier to plan a balanced sprint, taking only tasks that can be implemented (all cards with the priority “3” should be split into smaller tasks) and some small tasks that allow your team to reduce the workload.
MoSCoW pros and cons
The framework is quite popular among Agile projects with fixed timeboxes since it allows for managing the requirements for a specific release of a product. This prioritization method has proved its efficiency and reliability within our company as well, and we do recommend it to our clients. However, it is not perfect of course, and an unbiased look can reveal some flaws associated with MoSCoW technique. Let’s take a look at its strengths and weaknesses.
MoSCoW prioritization at Railsware
Let’s take a look at how we set priorities within the company.
Product development: we rest upon a roadmap where the product features and the order of their implementation are specified. As a rule, we leverage MoSCoW to define which feature goes first, which comes second, and so on, taking into account their importance and the interdependence of features. Must-haves and Should-haves are meant for the product release. Could-haves and Won’t-haves are postponed for the future.
HR and recruitment: prioritization rests upon such requirements as the demand for particular expertise, budget availability, timebox (how urgently we need this expertise), and so on. We leverage the similar patterns of setting priorities in other focus areas including on-boarding, branding, marketing, etc.
The biggest challenge of the methodology is that all stakeholders must be familiar with enough context to estimate features correctly. Besides, stakeholders that represent different functions like sales, development, marketing have their own vision of setting priorities, which not always works towards correct prioritization. Investors usually treat all features as Must-haves from their broad-based perspective and need them done without any respect of their implementation order.
Railsware has a Holacratic organizational structure. We take advantage of collective leadership based on the RASCI model and make decisions on different things including prioritization through voting. Team members can choose from several options like really want, want and don’t want. Each option implies a particular point. The option with the biggest point total has the highest priority. For small contexts, a responsible role (team leader, project manager, etc.) can be in charge of setting priorities on his/her own.
MoSCoW alternatives you may find useful for your project
Railsware uses Agile framework MoSCoW heavily and is pleased with it. However, it does not mean that we are closed to other solutions. Besides, a good product manager must consider the key product metrics and build the prioritization according to them. So here are some other worthwhile techniques that you may benefit from.
Kano Model
With this framework, you can define how happy the users are with product features. The Kano Model rests on a questionnaire, which is used to learn users’ attitude to a particular feature (like, expect, dislike, neutral, etc.). Visually, the model can be expressed via a two-dimensional diagram where the vertical axis is responsible for the level of user satisfaction (from totally frustrated to incredibly happy) and the horizontal one shows either how much was invested in the feature (Investment), how well was it implemented (Implementation), or how much users benefit from it (Functionality).
Categorization of requirements includes four types that are prioritized in the following order: must-be, performance, attractive, and indifferent. Must-bes are some basic things that users generally expect. Performance (also known as One-Dimensional) requirements are the golden mean and allow you to increase the satisfaction level. Attractive requirements are those that improve user experience. These are nice-to-haves or could-haves according to MoSCoW. Indifferent ones are less prioritized and sometimes even entirely omitted.
Value vs. Complexity
This prioritization technique is one of the simplest. You can encounter it under the names of Value vs. Cost or Value vs. Effort as well. The method feels intuitive and is aimed at maximizing value delivery. Estimation of features’ importance rests upon how much effort is invested to implement them and how much value they will bring. Here is how it looks visually:
Wrapping up
The art of setting priorities shows the efficiency of your workflow. Railsware’s choice is the MoSCoW project management framework, which has made a good showing in versatile functionalities and products. However, it might be less useful for immense projects with multiple teams involved in the pipeline. We advise you to find an effective prioritization solution that fits your unique needs, and to always avoid getting caught up in countless pending tasks.
Thanks for reading! Let me know your thoughts on this article, originally posted on Railsware's blog.