How important is the work for the project’s release or next step?
No team can do without a sensible prioritization of its pending tasks and work if it wants be even halfway efficient and not rush past customers’ needs in the development of a release or project.
Ideas and requirements come from every corner. They arise within the team itself, but customers also submit feature requests, competitor analyses bring new insights, stakeholders have requests and so on. The backlog of an average product team contains dozens, if not hundreds of ideas - and if the team doesn't bring any meaningful differentiation into it, they can't do any meaningful release or project planning. Further goal-oriented development would hardly be possible.
Attempts to prioritize all the ideas in discrete order - for example in the form of letters (A, B, C, D, ...) or numbers (1 to 10, 1 to 100 or similar) - will not get the team anywhere and will fail when things get a bit complex. We have already illustrated this in our blog post on prioritization according to the WSJF method.
While the WSJF is about generating as much value as possible with as little effort as possible, the MoSCoW method is dedicated to the actual importance and significance of a function or story for a release or project, regardless of the amount of work required.
Four clear priorities
Is task X essential for the release, a nice-to-have or even (initially) dispensable? The MoSCoW approach can give a clear answer.
The initials for this catchy acronym stand for:
M = Must (have)
S = Should (have)
C = Could (have)
W = Won't (have)
A “Must” requirement is a task that has to be implemented - it is a mandatory requirement. The release or project requires this step without any ifs or buts, it is non-negotiable (it is important that these features do not interfere with or exclude each other).
“Should” means that the work should be done as soon as the “Must” requirements are completed. “Should” features are important, but they are not essential for delivery. Since they have a lower priority than the “Must” requirements, they are treated as subordinate in case of uncertainty (and, for example, postponed to a later release).
“Could” requirements are subordinate. It would be nice if these functions existed, but their implementation is not necessary for the success of the release or the step in the project. They are only added when all higher-priority work has been implemented.
“Won't” work is the lowest priority. They are not implemented in the current release or project. This does not necessarily mean that the feature is fundamentally unimportant and dispensable. However, the implementation is not time-critical and can be looked at again at a later date.
Joint prioritization workshops create alignment
There are several methods to approach the prioritization of a feature or story in a targeted way. However, one basic principle is that prioritization should not be done by a product owner in private: transparency towards stakeholders and cooperation with them is crucial for overall alignment.
Therefore, it makes sense to hold joint prioritization workshops before releases or projects to get all stakeholders on the same page and create visibility. Several methods are available for prioritization workshops.
For example, the 6W approach helps answer six questions to describe each backlog item and its customer benefits in a factual, comprehensive and precise way. This form of clarity is a prerequisite for resilient prioritization. On the other hand, the user story mapping method allows the team to understand a customer’s journey when using a product and the activities and tasks they perform with it along the way.
However, all stakeholders should note that the MoSCoW priorities are not set in stone. Today's “Could” requirement may be tomorrow's “Must” feature. What is not considered a “Won't” in the current project may be prioritized differently in the next release and even perhaps during a completely different stage of development. Conversely, it is quite possible that current “Should” requirements will become obsolete at a later date.
Priorities can shift over time. Therefore, the team and its stakeholders are well advised to regularly review their priorities and reassess the relevance of their requirements.
Priorities that everyone can understand - also visible in Jira
The great advantage of the MoSCoW method is that the priorities are clearly understandable for everyone involved. Even people with less experience in the field can immediately get information about the importance of a feature or story for a project or release.
Ultimately, everyone involved wants and needs to be able to get this information at any time. It needs to be available beyond a physical board in the team room. In other words, it is necessary to map the priorities in the central digital system with which the teams manage their projects and tasks, aka in Jira.
The common way to do this is to use custom fields. And with the new app Awesome Custom Fields, this can be done easily and with the greatest possible visibility.
It enables teams to integrate MoSCoW prioritizations into their processes via custom fields (they can be changed at any time if needed).
In the prioritization workshop, the team can define the priority for each process according to the MoSCoW principle with one click.
The assigned priority is present in each ticket as a visual element. The priorities of the individual issues are also displayed on the maps of correspondingly configured Jira boards.
In the ticket, the priority is made visible in the form of a visual element.
The priorities of the individual issues can also be seen on the Kanban board if this is configured correctly.
Awesome Custom Fields makes the important and useful Jira feature, custom fields, more accessible, understandable and easier to use. MoSCoW prioritization is not the only predefined custom field that the app offers. With WSJF values, interactive progress bars, multi-user selection, star ranking, status tables, complexity estimates displayed in T-shirt sizes and more, Awesome Custom Fields offers fields for a variety of common use cases in agile teams - and more are added regularly.
The following short video gives a first impression of the app's possibilities, and if there is an increased need for Jira customization using Custom Fields in your teams, it is definitely worth taking a second, closer look.
You are currently viewing a placeholder content from Youtube. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
Awesome Custom Fields for Jira: Install now for free!
Awesome Custom Fields is available for free on the Atlassian Marketplace - and it's just the beginning. The development team is working hard to implement more use cases and provide even more configuration options. Later this year, the team will deliver several comprehensive features that will make working with custom fields even easier and more flexible, like being able to create custom fields at the project level.
Do you have any questions? Would you like to know more about the status quo and the future of the app? Would you like to see certain use cases implemented that are not yet available or planned in the app? Then get in touch: The team is looking forward to talking to you!
Further Reading
- The WSJF Method for Prioritizing Work – and Integrating It in Jira with Awesome Custom Fields
- Awesome Custom Fields: An Important Jira Feature Has Become More Accessible and Understandable
- 3 Steps To Make Your Sprint Planning Easier In Jira Cloud
- Templating.app Update – You Can Now Create Templates Across Multiple Jira Projects
- How to Easily Create Checklists in Jira
