7 Factors that could GUIDE Product Backlog Prioritization- "Agile Scrum"

Organizations are increasingly focusing on product strategy with a growing buzz for an agile manifesto. Team members in product intensive teams, formulate goals for the iterative approach of product development and tend to give a deep thought on what feature to implement first in the given timelines and product roadmap.

Elements like user experience have gained soaring importance amongst product management roles and design roles along with other factors. Having a plethora of options to choose from, a state of confusion usually is seen for prioritizing which feature to build when and for this reason, every organization has come up with a new version of backlog management. In this article, I will try to sum up which factors value for me in the journey so far. This list is definitely an ever-evolving one!

What factors guide backlog prioritization in product management?

1. Commercialization Targets- Commercialization of products can entail activities like marketing, production, customer support, sales goals, and others. Let’s assume that the current product goal for the year is to increase sales by 20%, but it was realized that 2 product features have now become obsolete. These features were being used by some initial clients but ain’t attractive to the new customers hence sales could be impacted the features aren’t enhanced and have planned obsolescence. 
2. Risk Mitigation/ Opportunity Enablement- Based on the incoming survey results, it has been observed that a given feature can mitigate a long-existing risk, then it would become crucial for the product team to adopt it on priority. Also, if the feature is capable of defending the current market position and uplifting it, then this could comport as a must for prioritization.
3. Financial Scrutiny- If building a feature is increasing the efficiency of the product components, then financial considerations shall matter. Like recently, while prioritizing product backlog for the last quarter, we prioritized excluding redundancies as a part of the upcoming release such that any development done henceforth could be effective, save time and help financially planning for other enhancements.

1. Resource & Personnel Analysis- Resource could be certain tools and software integrations required for carrying on the development process or people with certain skill-sets, or in a specific quantity who are not available until a certain time but will be in the future.

1. Stakeholders (Internal+ External)- If there are certain stories or tasks in the backlog that would keep the internal stakeholders or the external ones happy and engaged for a certain time in the future, then teams would consider picking those up against the other ones. While doing stakeholder prioritization, it's crucial to identify in which quadrant they could lie and what weight has to be given to that enhancement.

1. Complexity (Technical Feasibility)- Organizations these days are vastly using the concept of story points in Agile to determine the complexity of a feature/ fix based on the dependent technology. These are relative and easy to gauge the effort required to complete a story to another story that the team has worked on in past in similar modules. Story points include everything that can impact the effort like activities involved of various teams like development, quality assurance, and business analysis. Some features also tend to impact system stability and lead to changing other items and hence needs to be forced early.
2. Task Dependencies- If the feature has dependencies on other greater in size product backlog items- tasks and stories, then it could be prioritized accordingly by the product team. Usually, while creating the system architecture, the technical importance and order of development are identified so as to avoid rework and system instability going forward. If the components are reusable, it is safe to place them higher on priority as that could reduce future implementation effort and hence, needs to be implemented early.

It is not always one factor that guides the process, it is an amalgamation of different parameters in varied proportions based on the prioritization method you opt for and targeted goal.

Like, while opting for graduation, if I would decide for staying near to my hometown due to a certain reason, then I would take a decision based on proximity to my place (45%), better course offerings (35%), and maybe the program fees (20%). Then these parameters could be sub-classified for calculations and so on.

Many companies these days have started gathering idea recommendations directly from customers for reasons of inclusions and the need based on the votes from the community (audience size). In more product terms, if Spotify has to do an enhancement, it may take into consideration the new design principles (relevant, human, and unified) and a couple of other factors based on the short term goal. Spotify in its Idea Exchange forum picked up a requirement to prevent duplicates on playlists and the ability to subscribe to an artist as two of the features including many more.

Spotify determines the implementations based on:

·      Helping artists.

·      Data and other information collected.

·      Information from research testing, focus groups, and surveys.

·      Feedback in the Community and other support channels.

·      The overall short- and long-term business strategy. <Source: Spotify Community>

Generally, the weightage varies for a product based on the three considerations:

·      Speed of Delivery

·      Scope of the Product/ Release

·      Budget constraints

Priority Qualification Model/ Weighted Scoring Model in Agile Development

For the priority qualification method, relative sizing is preferred to bring every item on the same scale for comparison. A step by step approach is used to arrive at the final conclusion and the approach is explained below:

Step 1: Take the important factors to determine your prioritization for the year and create a list. I am selecting stakeholders (CSAT), Complexity (Story Size), Financial Consideration (Budget) and, Commercialization Targets (Sales Value)

Step 2: Opt for the scale to classify the chosen factors. For example, here, let us consider 1-10

CSAT- 10; Story Size- 6; Sales Value- 7.5; Budget- 4

Step 3: Now rate the items in the product backlog using a relative scoring method like we use Story Points for coming to a conclusion while judging the story size of an item.

The formula I use for scaling values:

Scaled Value= (Xcurrent- Xminimum)/ (Xmaximum- Xminimum) * Scale

Product Backlog Prioritization is, therefore, an ongoing task for product teams and requires regular brainstorming before scrum ceremonies kick in! This is just a starting list and I will add more such factors going forward based on my learnings and suggestions from the community.