How to Prioritize User Stories in Agile

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 and needs impact are usually lower than at the 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 first be to deliver the most valuable stories to your users or business. As you might already know, each story includes value to the user, but it can be difficult to prioritize a story based solely on that idea, which is sometimes unclear and sometimes too obvious.

Prioritization of  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 thoroughly explain 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". This method is recommended because it usually works better than any other simple method. This method's decreasing order of the different levels is based on priority. In this way, "Must-have" user stories are vital; lacking them would mean 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 with 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 is responsible for promoting a positive mentality and focusing on creating value for the user and the business and avoiding 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:

The product includes this feature. What do you think? (Functional perspective).

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:

Essential or mandatory features (O): These are the main features of your product that cannot be excluded.

Linear functionalities (L): This is called linear functionalities because adding more linear functionalities will increase the value of your product proportionally.

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.

Contradictory functionalities (C): In cases where there is a large difference of opinion between the working group participants, they may require more research.

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): These features 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. This approach's visual aspect is very good for helping to build a Product Backlog and also for helping you prioritize it. It is a great way for you and your team to visualize the priority of your product's main high-level features correctly.

Another very useful aspect of story maps is their ability to observe interdependencies between high-level features and see prioritization from the user perspective. They also give a clear view of which features might be less priority or purely technical.

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.

Portfolio and program levels usually need fewer requirements or User Stories than project levels. At the project level, User Stories with a value/business impact percentage are usually significantly smaller. This ultimately implies that at a portfolio or program level, the number of effective methods will be fewer. 

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.

At Simpliaxis, we understand the importance of prioritizing user stories and offer comprehensive training and support to help individuals and organizations enhance their Agile practices. Enroll in our courses today to gain the skills and knowledge needed to excel in Agile product development