In IT projects, the number of tasks that need to be done can initially seem overwhelming. Moreover, they all seem urgent from the point of view of the people involved. In such a situation, prioritizing tasks is not an option but a necessity to effectively manage time and resources.
A company can minimize the time and money spent on less important work by prioritizing what needs to be done. This enables all team members to work more efficiently, as they only deal with the most urgent tasks from a project perspective.
In addition, prioritizing requirements enables project teams to understand the amount of work and resources needed to complete each project element. This knowledge will improve the team’s time management, make the project more manageable, and increase the likelihood of completing it on time.
Table of Contents
How to start task prioritization
Prioritization takes place throughout the project work cycle. However, the initial prioritization occurs during the product workshop’s first stage, the Discovery phase, before work begins and assumptions are defined. With good planning, we know in what order we should arrange activities on the second day of the workshop, during the Event Storming phase, so that we start with the most important processes. To do this, we use a prioritization technique known as the MoSCoW model.
The MoSCoW method is actually one of many prioritization techniques out there. Dai Clegg, a software development expert, developed it during his work at Oracle in 1994. Clegg initially designed the technique for time-constrained projects and initiatives, and later, project analysts applied it to the DSDM (Dynamic System Development Method). Nowadays, it’s applied to tasks, use cases, acceptance criteria, and testing requirements and user stories.
The MoSCoW method is a popular technique for prioritizing and managing requirements. The acronym MoSCoW represents four categories of initiatives: Must have, Should have, Could have, and Won’t have.
Let’s discuss when and in what situations each category is applicable.
M – MUST (must have): Describes a requirement that must be met in the final solution. We could also call it a critical requirement because, without it, the product either will not work or will not meet the business objectives. An example of a mandatory action is, for example, confirming identity when opening an online bank account.
S – SHOULD (should have): Represents a high-priority item that should be included in the solution if possible. This requirement is defined before the start of the project and inserted for completion during subsequent phases.
“SHOULD” initiatives differ from “MUST” features in that we can plan them for the future without affecting the current situation. For example, performance improvements, minor bug fixes, or new features can be “SHOULD” initiatives. These would be beneficial to include, but without them, the product is still of value to the user.
C – COULD (may have): Describes a requirement that we can see as desirable, but optional. It will be included only if time and resources allow. A “COULD HAVE” task does not need to exist in the basic version of the product.
W – WON’T (won’t happen this time): Indicates a requirement that will not be implemented in the scope of the MVP, but may be considered in the future.
Placing a requirement in the “WON’T HAVE” category prevents the scope of work from expanding. The team then knows that the given initiatives are not a priority and do not need to be completed within a specific time frame.
Is the prioritization of tasks also done during the project?
When prioritizing tasks, it is essential to add that we review them continuously, not only at the beginning of the project. As new work emerges, whether through the introduction of a new requirement or the revelation of unexpected tasks, we analyze the impact of priorities on the success of ongoing work. Sometimes, we may need to reconsider individual development sprints or the entire backlog. We also review the importance of unfulfilled requirements throughout the project to ensure that they are still relevant.
When prioritizing, we always ask ourselves the following questions:
- What will happen if we don’t include this requirement in the project?
- Is there a more straightforward way to do this?
- Will the product work without it?
Advantages of the MoSCoW method, or why we like to use it
The MoSCoW method is easy to use and understand. It benefits project teams. When we look for the MVP of a product in a workshop, it helps to clarify the project’s needs, because not all tasks that are part of a sprint are necessary to achieve the sprint goal.
Other advantages of this technique:
- Simply defines priority categories – there are clear reasons why each task (feature) belongs to a particular category.
- Establishes a clear order of priority – product teams always know which products should be removed from priority first to make room for the highest priority products.
- Can be used at different stages of the product cycle.
- Enables good use of time – it clarifies what the team should work on first and what can be postponed.
Does the MoSCoW method have any disadvantages?
Although the MoSCoW method is efficient, unfortunately, it does have some disadvantages. One of them is that it does not include planning or hierarchical arrangement of tasks, and when categorizing requirements, it sometimes lacks a detailed description of them. Therefore, all “MUST HAVE” and “SHOULD HAVE” tasks should be approached carefully and, if necessary, grouped into the categories of other prioritization methods.
To balance this, we use a weighted scoring system in addition to the MoSCoW method when creating a project roadmap. This helps teams to measure each MoSCoW requirement and meets the standard cost-benefit criterion.
What is the weighted priority score system?
We don’t only assign priorities to general tasks M, S, C, and W, but we assign each task a value from 1 to 100. On this scale, 100 has the highest priority. The method is such that the digits between functions cannot be repeated, so if one feature has the number 70, no other function can have the same number. In this way, we determine the order of tasks in a series; for example, if we plan 10 tasks with a priority of “MUST,” we have to determine in which order to carry them out, depending on business needs. This can be summarized by saying:
“MoSCoW prioritizes the steps, and the scoring method determines their order”
Prioritization of tasks in Agile – project benefits
The MoSCoW technique is commonly used in Agile methodologies. It determines which elements – including tasks, requirements, products, and user stories – should be prioritized and which can be put on hold for a specific time.
Often, one of the reasons for using the MoSCoW technique is the need for greater flexibility of operations and faster detection of problems. We use the prioritization decisions to develop an iteration schedule that allows teams to implement solutions quickly and use resources more efficiently.
Interested in learning more about how our project teams work? Read the article below:
Summary
The benefits of the above analyses show why the MoSCoW technique is one of the more popular prioritization methods.
The MoSCoW technique shows us exactly what activities should be undertaken first and what can be left in the backlog. Using the tips in this article, you can prioritize your work, so that collaboration with your project team runs smoothly.
Do you have more questions about working with the project team or other issues related to application development? Contact us, and our experienced business analysts will be happy to answer your questions.
