In our introduction of the article about the MoSCoW method we have already pointed out the importance of a good prioritization of requirements. Now we would like to present two more methods that can greatly simplify project planning: The 100 dollar method and prioritization by ranking on a numerical scale.
The 100 Dollar Method
The 100 dollar method is great for prioritizing a manageable requirements pool with multiple or even many stakeholders.
The approach is simple: each stakeholder or voter receives 100 "dollars" or points. Requirements can be "purchased" with this limited budget. The stakeholder himself decides how much the realization of a specific requirement is worth to him. If all dollars or points are spent, the prioritization of the stakeholder is finished. All other stakeholders also go shopping with their dollars and prioritize the requirements that are important to them.
The result is usually a well-spread priority list. The limitation with only 100 dollars/points forces a prioritazion with caution. It is important that stakeholders from all involved departments participate in this prioritization process. The marketing department and IT will certainly bring different perspectives into play. For example, we had a good experience with a project in which more than 5 departments were involved. The distribution of the dollars/points was not made by a representative stakeholder. Instead, this task was assigned to the departments and teams. This triggered an internal discussion and evaluation of the individual topics within the departments, in which everyone could participate. The teams themselves also used the method described above to complete the evaluation and reported the results.
By the way, this method can also be combined well with other prioritization methods. For example, thresholds can be used to illustrate an association with the different categories of the MoSCoW method. Example:
- the requirement receives $500 or more in total: "Must"
- the requirement will receive between $200 and $500 in total: "Should"
- the requirement receives between $50 and $200 in total: "Could"
- the requirement receives $50 or less in total: "Won't"
Our experience is that this method is very well suited in situations where you have to work with many stakeholders and detailed discussions would take an immense amount of time due to this high number of people.
It is important that the results are not fixed. There should be space for fine-tuning and follow-up discussions.
Prioritization on a numerical scale
A widely used method for prioritizing requirements is to rank individual topics on a numerical scale from e.g. 1 (not important) to 10 (really important). The higher the number, the more significant this requirement is within the product/project. In the best case, requirements have been recorded in tabular form and the "weight" can be added as a new column. This ensures filterability and sortability.
Even though this type of evaluation is one of the simplest, we often observe that requirements are always very strongly ranked at the lower or upper limit of the scale. Requirements that are in the middle range are found proportionally less often, for the following reasons:
- Numbers are abstract. A classification with e.g. "important", "not important" is more concrete.
- A scale that is too large leads to uncertainty. The ratings are mostly oriented to the edges and the middle of the scale. There is hardly any rating in between.
A simple way to prevent this is to shorten the numeric scale to e.g. 1 to 5. Our experience is that this makes evaluations easier and eliminates insecurities.
However, this method also carries the risk that requirements are generally classified as very important for the project. It is up to the project managers to judge the final prioritization.
One advantage of assigning numbers is that each stakeholder can do this for themselves. For a final result, the rounded average value of each considered requirement is used.
Again, think about what thresholds should be used to differentiate requirements in the context of the project! Very low-rated requirements should either be excluded immediately or at least formulated as nice-to-have features. Transparent communication with the stakeholders is extremely important here! This avoids uncertainties and disappointments during the project.
Conclusion
Looking at the two prioritization methods introduced, we highly recommend the 100 dollar method. It has been shown that stakeholders make a more accurate judgement of the business value of a requirement with a limited number of "votes". In addition, the method can be adapted and fine-tuned to your own taste.
Evaluation with numbers is particularly effective for a manageable number of requirements and stakeholders. Here, almost nothing has to be explained and the results arrive more quickly.
Frank Schillinger is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/priorisierung-100-dollar-methode-und-skala/
Feature image: Photo by Alvaro Reyes on Unsplash
Latest comments (0)