Setting priorities in software projects

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.

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 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.

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 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.

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.

Author: IAPM internal