Priority rules for requirements

Who has right of way when several road users meet at a junction?

This question arises countless times every day on the roads. At junctions, intersections or narrow points, drivers, cyclists and pedestrians must decide for themselves within seconds who is allowed to drive or walk first. There is no time for lengthy deliberation.

To ensure these decisions are not left to chance, there is a legal framework: the Highway Code (StVO). It sets out the rules governing how such situations are generally handled and who has right of way under what conditions.

Anyone wishing to obtain a driving licence must learn and understand these rules. Millions of people apply them every day, often quite naturally and almost automatically. This is precisely why traffic flows surprisingly smoothly in most cases.

And this is exactly where the parallel with requirements engineering begins: there, too, different requirements come into conflict. Not everything can be implemented at the same time, which is why clear rules are needed to determine what is dealt with first. In a project context, we refer to these rules as prioritisation.

Who gets the go-ahead when it comes to requirements?

Prioritisation always comes into play when a decision needs to be made about what is most relevant or what should be implemented first. This is necessary because resources are limited.

In project management, we often talk about the triple constraint [1], with its three corners: time, budget and scope. All three are interdependent and often compete with one another. Both time and budget are usually external constraints over which we, as requirements engineers, have only limited influence. If the entire scope is to be implemented, it is precisely these two factors that often set strict limits. We must therefore deliver within a given budget and by a defined deadline.

To avoid using the available resources to implement features that offer only relatively little benefit to the customer, one should start with the most important requirements.

In road traffic, when approaching a junction, you must decide immediately who has right of way. The traffic rules prescribe a clear order for this: emergency vehicles first, then rail vehicles, then priority roads, and so on. The right-of-way rules on the road are clearly defined. But what about requirements engineering?

What is known as right of way in road traffic is known as priority in requirements engineering. According to the BABOK [2] of the IIBA [3], prioritisation aims to “rank requirements in order of their relative importance”. The starting point is existing requirements whose content has already been agreed. The result is a clear order of priority.

The specific form of these requirements can vary: user stories, features or epics. What matters here is not so much the label as the granularity. Epics are usually coarse-grained, user stories significantly finer-grained. It is important to compare like with like. So you prioritise epics or features or stories, but not all at the same time.

If we apply the logic of the highway code to requirements engineering, we could say:

• The road users are the requirements.
• The road is the backlog.
• The priority rules are the criteria that determine the order.

It is precisely these priority rules for requirements that we will now examine.

MoSCoW: Clear prioritisation with boundaries

A well-known prioritisation method is MoSCoW. [4] The term is an acronym formed from the first letters of Must have, Should have, Could have and Won’t have. Two small ‘o’s’ were added so that the word could actually be pronounced.

MoSCoW provides clear prioritisation rules: a simple yet effective system of four categories that helps teams and stakeholders decide together which requirement is allowed to ‘cross the junction’ and when.

Must have: Must-have requirements have absolute priority. If even one of them is missing from the current delivery timebox, the result is considered a failure. They form the non-negotiable minimum.

Should have: Should-have requirements are important but not essential for the current timebox. Much like a priority road, they generally take precedence but can also wait in certain situations. These requirements are often just as valuable as must-haves, but less time-critical or can be bridged by a temporary solution.

Could have: Could-have requirements are desirable but not necessary. They improve the user experience or user satisfaction without their absence fundamentally calling the product into question. They are put on hold first as soon as more important issues take priority. These requirements are incorporated into the planning if time and budget permit.

Won’t have (this time): Won’t-have requirements are deliberately excluded from this timebox by mutual agreement among all stakeholders. Access is blocked for the time being. The phrase ‘this time’ is crucial: these requirements are not permanently scrapped, but can be reviewed again in a later iteration.

Figure 1: Categorisation of requirements using the MoSCoW method

One of the great benefits of MoSCoW lies not only in the four categories themselves, but in the discussion they prompt. Just like in road traffic, clear rules are needed so that everyone involved knows who is allowed to go when and who still has to wait.

MoSCoW is particularly well-suited when requirements have already been agreed upon in terms of content, resources are limited, multiple stakeholders are involved, and many similar requirements need to be prioritised. In such cases, the method offers a simple and straightforward approach.

However, MoSCoW also has its limitations. If one relies solely on it, one works first on the Must-haves, then on the Should-haves, and finally on the Could-haves.
Once all Must-haves have been implemented, a project could even be considered successful from a purely methodological perspective, even though in practice no real project success is achieved. The reason lies not in the method itself, but in the fact that exciting or innovative requirements with lower priority remain in the backlog for a very long time or are never implemented at all.

Thus, ideas with great potential may be considered important, but not time-critical. They then end up in the ‘Should-haves’ or ‘Could-haves’ group and are ultimately dropped when time or budget constraints arise.

Kano’s priority rules: Not everything has the same impact

Back on the road. Imagine you’re getting into a new car. You take it for granted that the brakes work. Nobody would praise that as a special feature. It’s particularly important to you that the sat-nav is reliable and quick. The better it works, the happier you are. And the fact that the car automatically turns the music down when you’re parking? You wouldn’t have expected that at all, and that’s exactly what delights you.

It is precisely these three experiences that underpin the Kano model. [5] Professor Noriaki Kano investigated how delivered features influence customer satisfaction and came to a crucial realisation: not all requirements have the same impact.

He distinguishes between three categories: basic factors, performance factors and delight factors.

Basic factors are taken for granted. If they are present, they are hardly noticed. If they are missing, the disappointment is great and trust in the product is immediately damaged. In road traffic, this corresponds to a functioning infrastructure: intact roads, legible signs, working traffic lights. Nobody praises them, but without them the system collapses. In a car, these are functioning brakes, the seatbelt or the built-in radio.

In requirements engineering, these are the requirements that are taken for granted. They must be met, but do not generate any enthusiasm on their own.

Performance factors have a direct impact on satisfaction: the better they are implemented, the more satisfied users are. The poorer they are implemented, the greater the dissatisfaction. In road traffic, this corresponds to the quality of the road surface. A smooth, well-maintained road noticeably improves driving comfort, whilst potholes are just as noticeably disruptive. In a car, these are fuel consumption, the time taken to charge an electric vehicle, or the range.

These requirements are usually actively demanded by stakeholders. They are well-known, measurable and directly negotiable.

Excitement factors are features that nobody has explicitly asked for, but which trigger genuine delight when they are present. Their absence is not perceived negatively, whereas their presence is viewed very positively. In road traffic, this would be a diversion that not only bypasses the traffic jam but also takes you past a beautiful viewpoint. Nobody expected it, but everyone is delighted. In a car, this could be heated seats with separate settings for the back and the seat.

In a product context, these are often innovative features that customers only come to appreciate once they have experienced them.

Figure 2: Classification of requirements into factors of the Kano Model

The key message of the Kano model is this: a successful release requires all three categories. Those who deliver only basic factors keep the product alive, but fail to inspire anyone. Performance factors create satisfaction, but no real loyalty. It is only excitement factors that make a product stand out from the crowd. The trick lies in finding the right mix in every iteration and regularly checking whether your own assumptions still match the reality of the users.

Prioritisation with foresight: Combining MoSCoW and Kano

As can be seen, both methods have their pros and cons. It can therefore be useful to combine them. [6]

MoSCoW can initially be used to prioritise requirements based on technical criteria. By supplementing this approach with the Kano model, the impact on the user or customer is also taken into account. This ensures that necessary requirements are implemented whilst also taking into account the insights of the Kano model.

This can mean, for example, that the ‘Must have’ category contains all the requirements without which a project would be considered a failure. Within this group, however, one can further distinguish whether these are basic, performance or excitement factors.

This enables significantly better scope planning for a release.

However, this categorisation can also be applied to all requirements to identify how the entire backlog is distributed.

This can raise interesting questions:

• Are the ‘Must-haves’ distributed evenly, or do they consist almost entirely of basic factors?
• Are there sufficient performance and delight factors included?
• Are there perhaps even basic factors in the ‘Won’t-haves’ that should be reviewed again?

A typical warning sign would be the following distribution: ‘Must-haves’ and ‘Should-haves’ consist almost entirely of basic factors, whilst performance and enthusiasm factors predominantly end up in ‘Could-haves’ and ‘Won’t-haves’.

Figure 3: Combination of MoSCoW and Kano with an unfavourable distribution of factors across the categories

If one were to implement things strictly according to priority – that is, ‘Must-haves’ first, followed by ‘Should-haves’, and only then the rest – one would have worked methodically correctly, but would ultimately still have delivered a rather unattractive product.

To avoid precisely this outcome, it is worth regularly reviewing, supplementing or deliberately combining prioritisation methods. Often, valuable insights can be gained with very little extra effort.

AI in requirements prioritisation: A sat-nav rather than autopilot

Artificial intelligence has now made its way into requirements engineering. This inevitably raises the question of whether and how it can be usefully applied to the prioritisation of requirements.

As with many tools, the answer is: it depends. AI can provide support, speed up processes and offer new perspectives. However, it does not replace the team’s responsibility and decision-making.

There are several areas where AI can create real added value:

• With large backlogs containing hundreds of user stories, it can help to form initial clusters, subject areas or priority categories. This is often quicker and more consistent than lengthy manual workshops.
• It can analyse historical data and highlight which features were prioritised in the past or delivered the greatest added value. This supports data-driven methods such as RICE or WSJF.
• Furthermore, AI can mitigate human biases, such as the HiPPO effect or the dominance of particularly vocal stakeholders. Additionally, it can pre-sort requirements according to MoSCoW, Kano categories or other frameworks, thereby creating a solid foundation for discussions.

However, it is just as important to consider the limitations of this technology:

• Prioritisation is not a purely technical problem. It is often political, organisational and communicative. AI is usually unaware of internal tensions, strategic goals or informal dependencies.
• Strategic decisions, too, can only be automated to a limited extent. Why is Feature A implemented before Feature B? This often depends on market strategy, regulation, competition or corporate goals.
• Added to this is the issue of trust: if a team cannot understand why AI has given Feature X priority 1, there will be a lack of acceptance. Furthermore, AI is only as good as the data it works with. Unclear, contradictory or poorly formulated requirements also lead to poor results. And finally, responsibility always lies with humans.

That is why AI should be understood as a tool, not as a decision-maker. Sensible use looks like this: artificial intelligence makes suggestions, requirements engineering facilitates, and stakeholders decide. Just as in road traffic, one should not rely blindly on the sat-nav here either. The sat-nav makes suggestions, but the driving is still done by humans. We are still a long way from a true autopilot when it comes to prioritisation.

Prioritisation in practice

To ensure that prioritisation is carried out effectively and that the outcome delivers value for all involved, it is worth following a few tried-and-tested basic rules.

• Involve stakeholders early on: If stakeholders are brought in too late, this often leads to surprises, resistance or time-consuming renegotiations.
• Formulate requirements clearly: If requirements are too vague or incomplete, there is no basis for a meaningful assessment. This inevitably affects the prioritisation outcome.
• Define the time horizon: Prioritisation always applies to a specific period. A requirement may be very important for the overall project, but not necessarily for the next sprint or release. It should therefore be clear in advance what time frame the prioritisation covers.
• Compare like with like: Prioritisation can take place at different levels of granularity, such as for epics, features or user stories. However, one should avoid mixing these levels in a single round. Epics are more suitable for high-level planning, features for releases, and user stories for short-term implementation.
• Review prioritisation regularly: Prioritising once is not enough. Contextual conditions change, new insights emerge, and the importance of individual requirements can also shift.

Prioritisation is not rocket science. Often, simple rules, clear communication and a bit of discipline are enough. If you bear these points in mind, it will likely work not only in requirements engineering but also on the road.

Notes:

If you are interested in further information and perspectives on business analysis, modelling or cloud computing, it is certainly worth taking a look at Gottfried Szing’s blog: https://kjoo.be.

[1] Triple Constraint: How can a balance be achieved?
[2] The BABOK Guide is a guide for business analysts and describes knowledge areas, tasks, techniques and core competencies.
[3] The International Institute of Business Analysis – IIBA – is an organisation that promotes business analysis methods and techniques.
[4] MoSCoW method: What are the pros and cons?
[5] Kano Model: How does the bipolar survey work?
[6] There are other qualitative and quantitative methods that are also suitable for combined use:

• Stack ranking: simple but effective: organise all requirements into a single ordered list and force a decision rather than saying “everything is important”. This is effectively equivalent to sorting the backlog in familiar ticketing tools.
• Pairwise comparison: Each requirement is compared with every other (“Which is more important – A or B?”). This produces a clear order, but is time-consuming when there are many items.
• Weighted Shortest Job First (WSJF): Originates from SAFe (Scaled Agile). Here, you calculate the “Cost of Delay / Job Duration”, and the requirements with the highest ratio are to be implemented first. This is particularly useful when delays have measurable costs.

Would you like to discuss the prioritisation of requirements and the combination of methods as an influencer or thought leader? Then share this post within your network.

Gottfried Szing has published three more posts on the t2informatik Blog: