How important is a piece of work for the release or the project step?
No team can do without meaningful prioritization of its upcoming tasks and work, even if it only acts reasonably efficiently and doesn’t want to rush past the needs of customers when developing a release or project.
Ideas and requirements come from every corner. Of course, they arise within the team itself, customers also submit feature requests, competitor analyzes yield new insights, stakeholders have requests and so on. The average product team’s backlog contains dozens, if not hundreds, of ideas—and if the team doesn’t bring meaningful differentiation into this, they can’t do meaningful release or project planning either. Targeted further development would hardly be possible.
However, attempts to prioritize all the ideas in discrete orders – for example in the form of letters (A, B, C, D, …) or numbers (1 to 10, 1 to 100 or similar) – will spoil the team get nowhere and fail at the latest when things become a little more complex. We have already shown 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 addresses the actual importance and significance of a feature 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 accessory or even (initially) dispensable? The MoSCoW approach gives a clear answer to this.
In this catchy acronym, the majuscules stand for:
M = Must (have)
S = Should (have)
C = Could (have)
W = Won’t (have)
One Must-Requirement is a task that must be implemented in any case. It is a mandatory requirement. The release or project requires this step without ifs and buts, it is non-negotiable. (In this context, it is of course important that must 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 functions are important but not essential for delivery. Since the priority is lower than that of the must requirements, they are dealt with subordinately in case of doubt (and, for example, postponed to a later release).
Could-Requirements are secondary. It would be nice if these features existed, but implementation is not required for the success of the release or project step. They will only find their way in when all higher-priority work has been implemented.
Won’t-Work has 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 classification of a feature or a story in a targeted manner. A basic principle, however, is that the prioritization should not be carried out by a product owner in the quiet of a room: transparency towards stakeholders and cooperation with them is crucial for an overarching alignment.
It therefore makes sense to conduct joint prioritization workshops before releases or projects in order to get everyone involved on the same page and create visibility. Several methods are available for such prioritization workshops.
For example, the 6W approach helps to describe each backlog item and its customer benefit factually, comprehensively and precisely using the answers to six questions. This form of clarity is a prerequisite for reliable prioritization. The method of user story mapping in turn creates an understanding in the team of which journey a customer or user undertakes when using the product and which activities and tasks they carry out.
However, everyone involved needs to understand that MoSCoW priorities are not set in stone. Today’s cloud requirement may be tomorrow’s must feature. What is not considered a won’t in the current project may be prioritized completely differently in one of the next releases and in view of a completely different development stage. Conversely, it is quite possible that current should requirements will become obsolete at a later point in time.
Priorities can shift over time. Therefore, the team and its stakeholders are well advised to regularly review their prioritization and reassess the relevance of the backlog 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. They also give non-specialist and less experienced participants immediate information about the importance of a feature or story for a project or release.
Now it would be handy if this immediate visibility wasn’t just on the physical board in the team room. Ultimately, everyone involved wants and needs to be able to obtain this information at any time without leaving their workplace. So it is necessary to map the priorities in the central digital system with which the teams manage their projects and tasks – in other words: Jira.
The common method for this is the use of custom fields, i.e. user-defined fields. And with the new app Awesome Custom Fields this is particularly easy and with the greatest possible visibility.
It enables teams to integrate MoSCoW prioritization into their processes via custom fields. (These can be changed at any time if necessary.)
In the prioritization workshop, the team can define the priority for each process according to the MoSCoW principle with a click.
The assigned priority is present in every ticket as a visual element. The priorities of the individual issues are also displayed on the cards of appropriately 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 a correspondingly configured board.
Awesome Custom Fields takes the important and useful Jira feature of custom fields out of the technical corner and makes them more accessible, understandable and easy to use. The prioritization according to MoSCoW is not the only predefined custom field that the app brings “out of the box”.
With WSJF scores, interactive progress bars, multi-user selection, star ranking, status lights, t-shirt-sized complexity estimates, and more, Awesome Custom Fields provides fields for a variety of common use cases in agile teams—and counting.
The following short video gives a first impression of the app’s capabilities, and if your teams have an increased need for Jira customization using custom fields, it’s definitely worth a second, closer look.
Awesome Custom Fields for Jira: Install now for free!
Awesome Custom Fields is available for free on the Atlassian Marketplace – and is only at the beginning. The development team is working hard to implement more use cases and provide even more configuration options. Later in the year, the team will deliver several major features that make working with custom fields even easier and more flexible at the same time, such as the creation of 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? Do you wish for certain use cases that are not yet available or planned in the app? Then let me know: The team looks forward to talking to you!
Further information