Choosing priorities means deciding what will remain undone.
Helmar Nahr (*1931), german Mathematician & Economist
Whether in a classic or agile project context - those who do not know the focus points and what is important for achieving success are acting blindly. It's extremely important for all project members to get the focus points communicated in a transparent manner. However, the way to achieve this is often difficult. Starting with incomplete knowledge of the core requirements of the planned product and ending with the everything-is-important scenario: how can we resolve these issues and achieve a rational prioritization of the requirements to be realized?
Especially for large and multidisciplinary projects and products, the inclusion of important stakeholders from every department involved is crucial. We can classify requirements in a workshop or ask each stakeholder to do so individually.
We strongly recommend the collaborative development of this requirements prioritization in form of a workshop. Here we have the chance to ensure and promote communication and transparency between the stakeholders. This is the only way to achieve fundamental acceptance of the requirements from other business units or departments.
Important note: On the way to prioritization, you may often identify new requirements that emerge simply through communication between the project members. Under no circumstances should these requirements be put on top of a pile of "issues to be discussed"! Try to clearly document these new requirements immediately and add them to the pool of topics still to be prioritized. This way you can avoid a potentially very time-consuming reprioritization cycle.
In this and following articles, we want to highlight selected methods for prioritization. The result in each case is a transparently defined project scope or a rough topic prioritization of a product backlog.
By the way: in separate articles we will show you how to create a prioritizable topic pool.
MoSCoW
This method is helpful for a classification by criticality. MoSCoW is an acronym for the words "Must", "Should", "Could" and "Would/Won't/Want". The first letters of these words are combined with two "o". However, these have no meaning and only serve the purpose of forming a pronounceable term.
With the MoSCoW method, we assign requirements to the mentioned categories. This can be done in a wide variety of ways.
If the project is small, this can also be done with sticky notes or a bulletin board. Draw a grid that will allow you to classify the requirements. Write the requirements or higher topics with the desired degree of details on the sticky notes and put them into order after a proper discussion.
In case of an large pool of topics/requirements, you will have documented this information clearly in the best case. Perhaps even in tabular form. In this case you need only one more column, in which you can enter the respective classification. The advantage of a tabular documentation is for example filterabilty and sortability. Use appropriate tools, e.g. the classic Excel, and document clearly and precisely beginning with the first discussions with stakeholders.
Present the results of the prioritization to each stakeholder. This guarantees transparency and avoids "unpleasant surprises" during the project.
Achieve an agreement regarding the ranking of the individual categories! All stakeholders must be aware that a "could" requirement may not be included in the project scope. However, this does not mean that it cannot be made available in a future release!
Must
Requirements in the category "must" are, of course, to be considered absolutely necessary and are essential for the success of the product/project. Here, nice-to-have features are just as wrong as requirements that can easily be moved to a future release. Only requirements that have been classified as absolutely critical to the acceptance of the stakeholders and the targeted user group should be included in this category.
Simplified: What is the use of an online store in which I cannot enter a shipping address? What is the use of an appointment management application that doesn't allow me to manage these events properly? Products without central and essential functions miss their purpose.
Requirements in this category that have not been implemented by the end of the project usually affect the acceptance of the product/project. Under certain circumstances, the project is also considered to have failed - depending on the criticality.
Make sure that no more than 60 percent of the requirements are assigned to this category. Of course, this varies greatly depending on the project and the level of the requirements. Set individual goals so that you can plan the project well.
It should be mentioned again: a requirements pool that consists only of absolutely important topics is usually incomplete or not analyzed well!
Should
"Should" is considered as a category of critical and important requirements. These requirements strongly contribute to the acceptance and success and are definitely worth aiming for. However, they are not show stoppers if not met and do not cause an unavoidable failure of the project. In the simplest case, these requirements can be delivered in a future release.
Simplified example: In addition to the primary payment methods, another payment method needs to be available. Even if it makes sense from a strategic point of view to offer this payment method, it is not vital for completing an order or for the functionality of the online store.
Requirements in this category are very often candidates for a future release. This allows more space for the "Must" category and makes a project more predictable. Make sure that about 20 to 30 percent of the requirements go into this category. Again, of course, this depends on various circumstances and constraints.
Could
Requirements that are not crucial for success are the classic nice-to-have features, which are assigned to the "could" category. However, this does not mean that they are "worthless". If resource planning allows it, these requirements should also be implemented. They often increase acceptance - and for this reason alone, they should not simply be dropped.
Simplified example: When the customer signs in to the online store, he or she can be shown personalized product suggestions. This leads to higher acceptance of the store, but does not affect the basic functionality of the platform if the requirement is not met.
10 to 20 percent of the requirements should be optional requirements. As mentioned above, this depends on many factors.
Won't
Whether "Would", "Won't" or "Want" - the "W" is not clearly defined. However, it is obvious that this category should include all requirements that are excluded in the current project scope. Therefore, we mostly use "Won't" as an explanation. This does not mean that they will not play a significant role in the future! Especially in dynamic markets, priorities can change faster than some product owners or project managers would like.
This category can also be used for a general definition of requirements or features that are not to be implemented in relation to the planned project scope. Often the effort of documentation for this is questioned, since these topics are not being followed up anyway. We would like to point out that this information clearly contributes to transparency and understanding! In the simplest case, you can prove that features have not been forgotten, but have been wisely kept out of the project planning. The information that a feature will not be implemented is just as important as a project plan that shows all functionalities to be implemented!
Simplified: The online store should not offer a language selection "Chinese", as this market is currently irrelevant.
Conclusion
Use the potential of prioritization using the MoSCoW method presented here to be able to outline your project more clearly. A transparent definition of priorities is the foundation for a successful project planning and realization! And it does not matter if you plan it in a classical or agile way.
The next logical step would be to build a product backlog or define a project scope. By classifying the requirements, we have set ourselves some boundaries, so this step should now be much easier.
More information can be found at: https://en.wikipedia.org/wiki/MoSCoW_method
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/methodische-priorisierung-mit-der-moscow-methode/
Feature image: Photo by Irina Grotkjaer on Unsplash
Top comments (0)