How To Prioritize User Stories in Agile
Agile projects have a lot of uncertainty. You may grab a big chunk of User Stories from all the Stakeholders, including users, but it is not wise to start creating everything that is asked for. You need resources, and you won't know until you start developing what resources you would need for your User Stories. Moreover, to get resources, you need money, and you have to always keep the cost-effectiveness and Return On Investment (ROI) in mind before starting to build anything. So, you need to prioritize. You have many stories, but you must decide which you will work on first and which ones will be kept later. Prioritization of User Stories is essential for Agile Planning. It clarifies which stories have more value and can bring more success so that you focus on them first.
For setting the priority, the team members get together and vote on which stories to take up first. The critical thing to remember here is that prioritization should be done based on essential features that will enable a faster rollout of the product in the market or delivery to the customer. In this way, teams can self-organize, have a clear visual roadmap, and start working only on the most critical features instead of focusing on the ones that do not add much value.
How to prioritize User Stories
There should be three criteria for prioritizing User Stories. These are urgency, importance, and size.
Urgency: Prioritizing User Stories based on their urgency becomes critical. You will most likely get your priorities wrong if you miss an urgency. You can't bring back the time spent focusing on not-so-urgent issues. Therefore, it becomes imperative to identify the urgencies rightly. However, urgency can not be the only factor. If you focus on urgencies only, you may neglect other important issues. Here, you have to look at the importance of stories also.
Importance: It is not always true that what is urgent will be important too and vice-versa. But the importance of a User Story should always be mentioned in the priority. If you ignore the importance, it may eventually become urgent, bringing more problems. Here, you have to be proactive. It would help if you balanced importance with urgency though it may have implications. You can not prioritize anything based on customer follow-up only. Your best customer may follow up the least, but you will ignore them at your peril. Importance is not necessarily decided based on a customer complaining more or Stakeholders putting pressure on you. Just look at what is essential and don't let it become an urgency. If you decide on the importance based on the good behavior of your customer, you will have better control over your Backlog.
Size: Balancing urgency and importance is undoubtedly critical but balancing the size is also an essential part of the solution to building a Sprint. Of course, you would not want the progress in a Sprint to be hindered and to flow continuously, but you often start a feature and then see it getting blocked. Therefore, you must include stories of all sizes in your priority. If you have only big stories in your Sprint, these may have to be handed over in the middle of the Sprint, and then you may have to bring in small stories to fill in even though they may not be high on urgency or importance. This will result in slowing down the progress and could mean delays.
So, your priority should be a balanced mix of urgency, importance, and size, which will also bring balance to time orientation. Better utilization of time results in more productivity and better results. Having discussed the factors to be kept in mind, we now discuss how to prioritize User Stories in Agile. What can different methods be used to set the priority right? Here are a few methods used for prioritizing the User Stories.
MoSCoW
The first method we are going to describe to prioritize User Stories is the MoSCoW method. The term MoSCoW is expanded as Must have, Should have, Could have, and Won't have. And these are the basis on which User Stories are prioritized.
Must have: Must-have stories mean they must have a functionality critical to the project's success. So, they have to be implemented on priority. We can understand the criticality of these User Stories from the fact that if you don't implement even one must-have User Story, it may result in the whole project failing. So, these must-have stories are essential and must describe the minimum functionality that will make these stories feasible.
Should have: Should have User Stories that include some functionality, which, if the product has, will add a lot of value. These User Stories are also crucial for the success of the project. Although these stories are essential but are not as critical as the must-have ones and can be put off temporarily and implemented a little later.
Could have: These stories add some value and will be good but not essential. You can add these User Stories in the Sprint if you have some story points available. But they can be easily left aside if some unforeseen thing happens. You take up these stories only when you decide to implement them; otherwise, they remain in the Backlog.
Won't have stories with minimum importance and value. They are essential, but their value for the business doesn't count for much. So, these User Stories are taken up last. If they continue to accumulate, they may cause a heavy technical debt.
The complexity matrix:
This is the second method by which you can prioritize your User Stories. We have seen in the MoSCoW method how the stories are prioritized based on value, but here, the priority is decided based on the complexity of the User Story. And this helps in better decision-making. In the complexity matrix, story points are considered for setting the priority of User Stories. You can create a matrix with four boxes for categorizing four different types of stories. These are:
- The story has a high value and is not complex
- The story has a high value and is complex
- The story does not have high value and is not complex
- The story does not have a high value and is complex
If you distinguish the User Stories in that matrix, it will clearly show which stories you must take first and then which. So the prioritization will be clear. You will know which stories should be implemented immediately, which can be put off for implementation later on, and which should not be implemented at all.
The Hippo Method
The term Hippo expands to the Highest Paid Person's Opinion. And it could be someone in the top management, some customer, or even an investor but not very effective. This person runs the whole show and generally does not consult others when making decisions. This person decides which User Stories would be taken up first and which others would be taken in what order. This method is fraught with the danger of isolating and demotivating the team members. A Hippo would prioritize stories based on what is essential. It could prioritize such stories which are not even in the realm or are not essential, which could have been brought to their attention if he/she had spoken with other team members. This considerably reduces the team's effectiveness, and they cannot understand what is being done and why.
The iron triangle method
The triangle's three sides are time, cost, and scope, which allows you to make vital decisions. Time is a critical factor in the success of any project. Any undue delays may derail the project or lead to confusion. But you can't compromise the quality to meet the deadlines. So, these things should be factored in while prioritizing the User Stories. But again, the time required to complete a project will largely depend on the project's scope. The bigger the scope, the more time required. You must have the time and resources to meet the deadlines and maintain quality. And, of course, the enormous scope would mean the need for more resources, which involves cost. You may be tempted to raise your budget, but that alone will not suffice. Only more money and more people can't always complete a project faster. What happens is that many times features and stories are not distributed evenly among the Developers. So, it boils down to the scope of the project. This is one thing you can control. Therefore, you have to be practical while deciding about the scope of your project so that it can be completed within the available time frame and budget. So, it would help if you prioritized your User Stories in your Backlog.
So, this is how to prioritize User Stories in Agile. If you correctly assess your User Stories' urgency, importance, and size, you can set your priorities right. You may adopt any method that works for you, but the aim has to be to arrange the User Stories to not compromise on quality or time. Keeping the team in the loop, so they clearly understand the priorities and are engaged is as important as the correct prioritization of User Stories. After all, you are ultimately working for the success of your project and customer satisfaction.
References:
- https://fusionalliance.com/how-Agile-product-owners-should-prioritize-user-stories/
- https://paper-leaf.com/insights/prioritize-user-stories/
- https://medium.com/swlh/prioritizing-user-stories-in-Agile-projects-d1dd8dd79165
