Prioritizing backlogs can be a daunting task full of tough decisions, especially on a tight deadline or a critical feature release. So, it's natural for product owners to wonder: “How should you know which backlog item to work on next?"
Everyone has a different perspective while looking at a backlog. The UX team wants to have new screens and flows implemented, while sales wants to have new features as soon as possible so they can sell to customers more effectively, and so on.
Ideally, your product backlog should be a list of useful, product-related tasks that your team needs to complete, and not items such as prioritizing the task-level details on the strategic plan set forth in a product roadmap.
Remember that a well-prioritized backlog is intended to make your iteration planning easier and align everything that the team intends to spend time on. It’s the sole responsibility of the product owner to manage the product backlog without compromising on the content, availability, and priority of the backlog.
If there are a large number of lower-priority items on the list, it shows that the product owner isn’t thinking strategically about the ways to prioritize the backlog.
Ideally, the work at the top of the list should be the most important and should be done first on a priority basis. There are many ways to prioritize your backlog, but the first step is to identify the potential issues that lead to cluttered or disorganized backlogs.
When considering a default approach for managing the backlog, it's important for your team to take the product owner role seriously.
There should be one person—no more, no less—responsible for the backlog of each scrum team. Ideally, that person is only responsible for one team backlog as well. That person needs to have plenty of time available for maintaining the backlog in collaboration with the team and external stakeholders. They need to be knowledgeable about the product and have the authority to make decisions within the backlog without the involvement of other parties.
Challenges commonly faced by product owners include:
Make sure you don’t forget to consistently review and adjust. If you work in Agile, there are chances that your backlog requires ongoing adjustment. Make sure you review and update your product roadmap periodically, from as frequently as every 3 weeks to no longer than 3 months.
Product backlog prioritization is not a science–thus, what may work for one PM might not work for another. Below, we have listed four backlog prioritization strategies that have been broadly adopted and have shown good results when it comes to backlog management.
No matter which approach you select, make sure to create a simple and clear strategy of how you will manage your backlog and involve the team in the entire process. The product owner holds the responsibility to maintain the backlog, but they're not the only one that contributes to the vision. It’s your responsibility to ensure that everyone on the team can and should contribute, and that they continuously participate in the process of keeping the backlog fresh.
If you want your chosen strategy to work properly, then everyone needs to have a rough understanding of how the backlog is managed, as this is the product's vision and roadmap. The key is to have a systematic approach that you can gradually improve on.
In this technique, you compare every item on your list and place it in the order of priority. Start with the highest-priority task, i.e. one, followed by two, three, and so on until n, which is the total number of items in your backlog.
Using this strategy, the top items on your backlog aren’t just “top priority” tasks with no internal dates associated with them—they also have a built-in timeline: your next sprint.
The following are some of the advantages of stack ranking:
A. There can only be one order: This will help you avoid a common and stressful pitfall where everything becomes a very high priority and there is no clear picture of what to do next.
B. It is often more accurate and less confusing: You have prioritized all items relative to other items, which simplifies the procedure and makes it clear. Thus, it is an accurate and easier way to prioritize than to provide absolute values (such as “very high priority” or “high priority”).
This model was developed by Professor Noriaki Kano in the 1980s. Under this model, features are categorized according to their needs and expectations of customers. Currently, there are many versions of the Kano Model, however, the original model uses five key thresholds: Must-Be, Attractive, One-Dimensional, Indifferent, and Reverse.
Must-Be: These are often taken for granted by customers, as these features will not necessarily wow them, but they must still be included in your product and cannot be ignored.
Attractive: These are the features that are loved by users, but their absence will not disappoint them if they are missing in the product because they weren’t expecting them to begin with.
One-Dimensional: These are the features that will be noticed by users if they are not there, and their absence will make users unhappy.
Indifferent: These have no impact on customer satisfaction levels. For example, refactoring parts of your code so that it is easier to read and understand. There is no direct value to the customer, but it will make it easier for you to maintain in the future.
Reverse: These make users happy in their absence and unhappy when they are present. For example, you might implement high-security features by requiring an extra step to log in. However, like most people who do not like extra steps for login, they would become extremely unhappy every time they visit the product or website.
Why use this model?
The Kano model is highly successful in organizations that tend to use “Must-Be” features. But to succeed, you also need to add one-dimensional features and deliver it attractively.
When dealing with a limited amount of time, budget, and development resources, product managers tend to shift to this scaling system to prioritize backlog items. A similar system should be used for every item to ensure that you realize the benefits and reduce the cost of your product backlog.
Metrics can include “Customer Value,” “Increased Revenue,” “Implementation Costs,” or some other important metric to score the items in your product backlog and sort the list with ease, without compromising on any important factor.
This is another good way of prioritizing your product backlog. You can select the best one or two ideas and break them into stories, tasks, and plans that your team can start working on.
This approach keeps your list as lean and realistic as possible.
It is the decision of the product manager to shift to a different prioritization strategy for their backlogs if the present strategy is not working for them. Having a backlog in the first place already represents a lack of efficiency in an organization, so it's essential for PMs to monitor the health of the backlog in order to determine if a strategic shift is necessary.
If you're struggling to identify opportunities for improvement, you can divide your team and product backlogs into several stages in which the Design in Progress (DIP) limit becomes more restrictive when you are closer to implementation.
The simplest approach would be to dedicate one portion of the backlog to all new ideas, and another portion which is more thoroughly confined in size. When an idea is moved to the more constricted stage, it serves as a clear signal from the product owner that the idea will eventually be implemented. It also creates a clear bottleneck to help you identify whether your backlog is getting out of hand.
If you're struggling to keep your backlog under control, then you can hire expert PMs and developers from Crowdbotics to strategically clear your backlog. Crowdbotics PMs are highly experienced when it comes to product strategy and task prioritization, and they can work with your existing team or manage an entire custom build from scratch. Get in touch with us today to learn more about how to clear your backlog fast.
November 19, 2020