Requirements/User Stories are frequently smaller in number at the Program or Portfolio level than in the Project level. Also, in the same way, User Stories with ponderable levels of values, needs impact are usually lower than at project level percentage wise. Altogether, what this means is that at a Program or Portfolio level, the range of tools that will be applicable will be smaller.

The moment you already have a collection of User Stories in your Product Backlog (in addition to features, requirements, improvements, changes and corrections, among others), you need to assign its priority. If you work with Scrum, at the moment you already have a collection of User Stories in your Product Backlog, as well as features, requirements, improvements, changes, and corrections, among others, you need to assign them to order, estimate and value so that they are selectable for the next Sprint.

Your goal as a Product Owner should be, first of all, to deliver the most valuable stories to your users or business. As you might already know, each story includes the value to the user, but it can be difficult to prioritize a story based solely on that idea, sometimes unclear and sometimes too obvious.
 

How to prioritize User Stories 
 

If you often question how to prioritize User Stories in Agile, do not worry, we have all the answers for you! Of course, to prioritize correctly, the Product Owner must use a large number of variables, methods, and tools. In the following pages, we will go over some of the most used and respected prioritization methods:  MoSCoW, Kano, comparison in pairs, 100 Point Method, and story mapping. Next, we will give you a thorough explanation of how each method works, and how it will help you prioritize User Stories in your projects.
 

1. MoSCoW Prioritization Method
    

This first method acquired its name as an acrostic. It uses the first letters of the words "Must Have", "Should Have", "Could Have" and "Won't Have". What makes this method very recommended is that it usually works better than any other simple method. The decreasing order of the different levels this method proposes is based on priority. In this way, "Must Have" User Stories are the ones that are vital, and lacking them would mean that the product has no value. The "Won't Have" User Stories are the ones that even if it would be good to have them, it is not vital to include them.
 

MoSCoW is a medium-term prioritization method. It consists of sorting your User Stories into different categories:
 

M – Musthave: What is described in the User Story must be developed compulsorily.
S – Shouldhave: The User Story should be developed if possible.

C – Couldhave: It could be developed, but it is not essential for users or business teams.

W – Won'thave: It won't be included in the medium term, but it could be useful in a later version.

Organizing a MoSCoW working group with stakeholders from different fields can be a great way to start prioritizing your backlog, but this method comes with certain limitations. For example, participants often think that "everything is important”, so all stories usually end up in the "must have" or "should have" groups. This often happens because everyone has a different point of view, and each story is important to someone concrete.
 

It also happens in companies in which there are usually unrealistic expectations or when the Product Managers or Project Managers do not know how to say NO. In these cultures, participants are convinced that anything that is placed in "could have" or "will not have" can also end up in the trash.
 

The Product Owner has the responsibility to promote a positive mentality and focus on the creation of value for the user and the business and avoid competitiveness between departments or people regarding what should be built.
 

2. Comparison in pairs
 

This second technique basically consists of having a list prepared with all the User Stories of the Prioritized Product Backlog. Then, each User Story is considered individually and is put against another User Story in the list, one by one. This way, User Stories are put side by side in order to decide which is more relevant than the other, allowing you to enumerate the priority User Stories, resulting in a very handy list. 
 

3. 100 Points Method
 

Dean Leffingwell and Don Widrig developed this next method in 2002. It consists of 100 points that must be assigned to the customer to vote with them for the User Stories that are principal. The goal is to give more importance to highly prioritized User Stories in comparison to the others available. Each member of the group assigns a value (expressed in points) to the different User Stories. Of course, in this way, they would give a higher score to the stories they think are more significant. Once this voting procedure is done, they calculate the total points that have been assigned for each story and then create the priority list. 
 

4. Kano Analysis
 

This method was created by Noriaki Kano in 1984, inspired by the asymmetry of user satisfaction and dissatisfaction with a feature. Some features may offer little satisfaction when they are present, but their absence can in turn cause great dissatisfaction.
 

When the Product Backlog is particularly old and thorough, the Kano method will allow you to prioritize the main features you want to include in your product. This method is also collaborative and should be carried out in a four-step working group with several participants
 

Step 1:

Identify the features you need to prioritize. Keep in mind that a feature does not have to be equivalent to a User Story, but to the sum of several; this will be defined based on your product and how specific your User Stories are.
 

Step 2:

Pose these questions to each member of the working group:

1. The product includes this feature. What do you think? (Functional perspective).
2. The product does not include this feature. What do you think? (Dysfunctional perspective).
    

Step 3:

It compares discrepancies between functional and dysfunctional perspectives and classifies features into these types:
 

1. Essential or mandatory features (O): These are the main features of your product that cannot be excluded.
    
2. Linear functionalities (L): So, called because, adding more linear functionalities, will increase the value of your product proportionally.
    
3. Exciting features (E): They are not essential, but they can be a great addition and please users. They are new features, or of great value to the customer.
    
4. Contradictory functionalities (C): For cases where there is a large difference of opinion between the participants of the working group. They may require more research.
    
5. Questionable (Q): They are characteristics that, if not present, may cause the customer not to like the product, but do not affect the level of satisfaction if they are present. You would have to try to figure out why they like these features so much or so little. Hopefully, this shouldn't happen very often.
    

Indifferent (I): They are the features that will not affect the customer in any way and should be removed. People are usually indifferent to these features and, logically, they should not be a priority. Hopefully, you can iterate on them to put them in the categories O, E, or L.
 

Step 4: Visualize your results in a diagram

The last step is to graph your results in order to be able to visualize them in an easier and faster way. We find this method particularly interesting because it is based on users' perception of the product and often reveals surprising expectations from some of the stakeholders.
 

5. Story Mapping

The last method is Story Mapping. The visual aspect of this approach is very good for helping to build a Product Backlog, and also for helping you prioritize it. Having said this, it is a great way in which you and your team will be able to have a correct visualization of the priority of the main high-level features of your product.

Another very useful thing about story maps is the ability to observe interdependencies between high-level features and see prioritization from the user perspective, as well as to give you a clear view of which features might be less priority or purely technical.

Simpliaxis is one of the leading professional certification training providers in the world offering multiple courses related to Agile methodologies. We offer numerous Agile related courses such as Certified ScrumMaster (CSM)® Certification Training, Certified Scrum Product Owner (CSPO)® Certification Training, Certified Scrum Developer (CSD) Certification Training, Agile and Scrum Training, PMI-ACP® Certification Training, Professional Scrum with Kanban™ (PSK) Training, Certified Scrum Professional® - Product Owner (CSP®-PO) Certification Training, Agile Sales Management Training, Behaviour Driven Development (BDD) Training and much more. Simpliaxis delivers training to both individuals and corporate groups through instructor-led classroom and online virtual sessions.

Conclusions

It is interesting that, usually over time, the features move down the ranking list. Customers will assume the existence of features and these will move from being exciters/delighters to satisfiers and, eventually, dissatisfiers.

In short: In comparison to a project level, portfolio and program levels usually need fewer requirements or User Stories. It is usual that at the project level, User Stories that have a value/business impact percentage are significantly smaller. In turn, this ultimately implies that at a portfolio or program level, the number of methods that can be effective will be less. 

The key to prioritizing your backlog properly is to do so by collaborating with various stakeholders and understanding the product value, as well as its strengths and weaknesses, from various perspectives and using a number of different criteria.

This will allow you to understand the value of a feature from a more global point of view, which will ultimately allow you to successfully make a decision about the features that you should develop primarily and which others can be addressed in the second place, further on the product life.