Setting priorities in software projects

Prioritisation is an everyday task in project work, both in traditional and agile project management. Especially in agile project management, or more specifically in Scrum, prioritisation plays a significant role because the Product Backlog must be prioritised so that the Product Backlog Items can be implemented according to their importance. When one thinks of agile project management, the software industry immediately comes to mind. Therefore, it is not surprising that prioritisation plays an important role there. You can find out how to set priorities correctly in your software project here.
A person writes in a notebook.


Prioritise to make decisions easier

Decisions often have to be made quickly, but that doesn't mean that all decisions made on gut instinct are good or purposeful. Therefore, it is important that decision-makers have all the information they need to make an informed choice. But it is not just about having all the information, it is also about having a basis for the decision. This is where prioritisation comes in. If the prioritisation has been done in advance and the decision maker is aware of the prioritisation, it can be incorporated into the decision, it can be made faster and wrong decisions are minimised. At first glance, wrong decisions seem to be the greater evil in this scenario, but especially in software projects it is important that decisions are made quickly, because especially in the technology sector, time advantage over competitors is a decisive factor in gaining an advantage in the market. The first product of its kind has the first mover advantage and thus a clear economic advantage.

Don't lose sight of the goals

In order to prioritise properly in software projects, it is necessary to have goals in mind. In Scrum there is the Product Goal, which tells the Developers where the journey is going, so that they can prioritise accordingly. But even non-Scrum software projects have a goal to work towards. This is motivating because the developers see that they are getting closer and closer to the goal. On the other hand, it also helps with prioritisation. The necessary steps can only be taken in the right order if the goal is known.

Estimation and prioritisation go hand in hand

Estimation is as important in Scrum as prioritisation. The Product Backlog is prioritised and the Product Backlog Items (PBIs) are estimated to find out how many PBIs can be realised in a development cycle. However, the estimation of each PBI is done after the items have been put in the right order - the implementation takes place after the estimation. Estimation represents the transition from the planning to the implementation phase. As usual, this does not only apply to Scrum. Even if the software project is to be implemented using a different approach, it makes sense to estimate the individual activities so that, in combination with prioritisation, the customer can see roughly when he can expect which feature. Both estimation and prioritisation are very subjective activities, and the more you do them, the better you get. But even if you have estimated or prioritised a lot, you can sometimes make a huge mistake: completely misjudging the scope or time required, or giving an activity a priority it does not deserve. But that is human. You just have to keep at it, incorporate such misjudgments into future estimates and prioritisations, and get better at it.

3 Models that help with prioritisation

As mentioned in the previous section, prioritisation is very subjective. If you ask five different stakeholders what their priorities are, you are likely to get five different answers. Everyone wants to see what is most important to them implemented first, so it is not surprising that priorities will vary. However, to avoid a situation where only a few project participants are imposing their subjective will, it is advisable to prioritise using a model to achieve a degree of objectivity. A combination of models is also possible and in many projects it can help to improve prioritisation by looking at problems from different angles.


In the MoSCoW model, a distinction is made between requirements that Must be implemented, requirements that Should be implemented, requirements that Could be implemented and requirements that Won't be implemented. First, it should be determined which requirements are to be placed on the product in the first place.
The next step is to draw up a list of criteria that must-requirements must fulfil. These include, for example, that the product cannot run without the requirement or that the requirement is prescribed by law.
Should-criteria are criteria that, together with the must-criteria, make up the product, but can be omitted or postponed if budget or time require it. However, it is important to remember that the absence of this requirement can lead to great stakeholder dissatisfaction. This includes automating certain steps: it makes the processes more efficient, but the product can be successful without automation. Implementation at a later stage is advisable.
Could-criteria, on the other hand, are "nice to have" but not absolutely necessary for the product - users will benefit from them, however, so it may be important to keep an eye on these criteria and implement them when the time or budget is available.
Won't-criteria are not implemented for this particular product. However, since they were included in the requirements pool for a reason, they are moved to an idea pool so that they are not forgotten and can possibly be considered for other products.
Ideally, 60 % of the product features should be must-features and 20 % each should- and could-features. However, in practice it often happens that all requirements are Must and Should. In this case, it makes sense to supplement the prioritisation with MoSCoW with another method.

Opportunity scoring

Opportunity scoring is about identifying an opportunity and prioritising it in such a way that the greatest benefit for the product is achieved on this basis. To do this, it is first necessary to determine where the opportunity lies in the first place, i.e., which functions are desired by the customers in a particular product and in which of these functions the customers are dissatisfied and still see potential for improvement. This can be done either by improving the product while it’s already on the market, or by finding out which product already exists - e.g., from a competitor - but the customers are not satisfied with it. This gap between customer desire and dissatisfaction must be closed because this is where great potential lies. Once the gap has been identified, the steps to close the gap must be found and prioritised. It must be considered which step makes the most sense to take first in order to increase customer satisfaction and profit from it.

Kano model

The Kano model graphically represents the relationship between customer satisfaction and fulfilled quality attributes. Customer satisfaction ranges between low and high and the quality characteristics can be represented on a scale between not fulfilled and fulfilled. In the Kano model there are three central characteristics:
  • the basic attributes,
  • the performance attributes,
  • and the attractive attributes.
The basic attributes are assumed by the customer and if the product does not fulfil these features, the customer is disproportionately dissatisfied or rejects the product. For example, a smartphone that is not suitable for making phone calls would not fulfil a basic feature. The priority of realising these features is high. Performance attributes are actively demanded by the customer - the priority is medium-high and comparable to the should-criteria of the MoSCoW model. To stay with the smartphone example: A good screen resolution is a performance feature. Attractive attributes are not self-evident and are not demanded by customers because they do not know that they will be enthused. An example would be an excessively long battery life without sacrificing the smartphone's resolution or looks. This is where it gets complicated, because these features are the lowest priority because they don't contribute to the product working at all - but when a product has these features, it clearly stands out from other products of its kind. At this point, the team has to find a way to integrate these features without getting lost in them.

Final words

Setting priorities is fundamentally important in project management, and software projects benefit from this in particular. After all, software projects in particular thrive on standing out from competing products and providing tangible benefits to users. In this area, it is important to deliver the right function at the right time in order to have a market advantage. To achieve this, the desired functions are prioritised and implemented accordingly. In order to create a common basis, it makes sense to consult prioritisation models so that this can be done as objectively as possible. In this way, the requests can be processed in the most appropriate order, helping to ensure that the product provides added value to the user and, ultimately, economic benefit to the company.

Priorities in software projects - The IAPM logo.
Author: IAPM internal
Keywords: Project Management, Prioritisation, Agile Project Management

The IAPM certification

The certification can be taken via a reputable online examination procedure. The costs are based on the gross domestic product of your country of origin.

From the IAPM Blog

Become a Network Official

Do you want to get involved in project management in your environment and contribute to the further development of project management? Then become active as an IAPM Network Official or as a Network Official of the IAPM Network University. 

For better readability, we usually only use the generic masculine form in our texts. Nevertheless, the expressions refer to members of all genders.