Product Backlog is always packed with various items you need to address.
The main problem is there are only so many hours in a day and dollars in a budget. You have to get your priorities straight and decide which features to work on first.
The best way to go about it is to embrace a systematic approach to Scrum prioritization.
For it to work, the teams have to share the responsibility of figuring out high-priority items and tasks. At the same time, the Product Owner needs to take a lead role in the process.
This arrangement gives everyone a clear focus and equips the organization with tried and tested tools. It’s your chance to put an end to messy and costly queues.
Bucket Approach: MosCoW
Bucket-style approach is the most rudimentary prioritization technique.
It poses a nice, beginner-friendly way to start the Backlog from scratch. It’s used in MosCoW and Kano models, which features buckets of items with varying degrees of needs.
We would start with MosCoW model born out of Agile Software development. It takes a product-driven vision and its letters stand for Must Have, Should Have, Could Have, and Won’t Have. These categories are self-explanatory for the most part.
For instance, Must Have and Won’t Have features are on the opposite sides of the prioritization spectrum. The former are critical to the point of making or breaking the whole project (due to safety, legality, usability, etc.). The latter are stories that teams decide to ditch or postpone for later.
Once you sort out initial prioritization, you need to engage in ongoing refinement and grooming. This means you don’t have to get everything absolutely right at the get-go.
Kano model was developed back in the 80s.
It gauges value from the user’s standpoint. In other words, value is a measure of how much an item adds to the users’ life.
It can be tracked via multiple parameters, such as user needs, expectations, and satisfaction. They all have profound implications on the market performance of the company.
In the original version of Kano, there are five key thresholds. These are Must-be, Attractive, One-dimensional, Indifferent, and Reverse. As the names suggest, they affect customers differently.
Must-be (not the same as Must Have in MosCoW) is a feature with a wow-effect, which has to be in the Backlog. On the other hand, an Attractive feature induces happiness. Its absence doesn’t bother them like in the case of missing one-dimensional feature. Indifferent features have no effect on satisfaction, while Reverse ones merely make users unhappy.
It’s clear these varieties aren’t created equal. What paves the way to market success is a balanced mix of Must-be, attractive, and one-dimensional features.
Linear Stack Ranking
Next off, we have a method that revolves around stack-ranking the Backlog in a linear fashion.
This is sometimes a more prudent approach than grouping the features together into priority buckets (Low, Medium, High, and Critical). You simply assign numerical values (1, 2, 3, 4, 5, etc.), which can each represent only one item at a time.
Items refer to features, epics, stories, etc. They don’t bear the same relevance and your framework should reflect that.
So, every item is prioritized relative to other items, rather than having an absolute value. Some of them can be tackled in average-length Sprints because they involve a low scope of work. Others, such as Epics, must be broken down into stories during Sprint Planning or some other time.
Overall, this is an easy-to-grasp and accurate framework. It tends to minimize inflation of priority and tells you exactly how important each Backlog item is. Therefore, the linear stack ranking improves decision-making and encourages transparency and honesty.
Total Effort: Value vs. Cost
Consumer-oriented approaches have their limitations.
Namely, a feature that has relatively low value for users may also require low effort. This means it shouldn’t fall too low in the Backlog.
In more general terms, sound prioritization always accounts for invested effort and costs. These two are local, team-dependent values, not global parameters.
This methodology reminds us teams have to undergo costly activities of training, development, delivery, deployment, testing, and customer support. Each feature demands some portion of available resources (cost of implementation).
Effort can be estimated according to story points as well. This works out particularly well in the cases of small and single-team projects. In other instances, these points could be a less-than-reliable proxy for project management.
With large projects, for example, you have to factor in variances of scale. Here, normalization is a way to recalibrate the points and make them a useful guide for your activities. Value vs. Cost technique yields results for ordinary backlog items and epics alike.
It accurately predicts the relative effort of handling features and work items.
User Story Mapping Method
Story Mapping attempts to overcome the limitations of a standard Product Backlog.
It does so by providing a more detailed structure for navigating the minefield of decisions. And the good news is the basic setup is quite simple.
There’s a horizontal axis, which serves as a sequence of use. You place user stories or tasks according to the order in which they are performed by the users.
As for the vertical axis, it denotes criticality. Tasks and stories appear relative to how crucial they are. Two items that have equal importance can occupy the same height. Actions are in the space above the vertical axis, which means they aren’t sequenced.
If you identify groups of interconnected user stories, you can cluster them as Activities. It’s a good idea to use vertical lines to separate these task groups from one another.
The advantage of Story Mapping is its visual nature. It stands at everyone’s disposal, including the customers, teams, stakeholders, etc. It shows you exactly how to build product iterations and deliver releases.
Time to Bring it All Together
As you’ve probably realized, there’s no single best way to prioritize.
You have to pick the approach that makes sense for your unique case: both your business and customer needs.
The beauty of it is techniques we covered are customizable and actionable. They call for collective judgment and consensus on the part of cross-functional teams and Product Owner. It’s not a perfect science, but it’s as close to it as we can get.
Just bear in mind that prioritization is a dynamic thing that changes over time. Thus, get ready to readjust on the fly, based on fresh insights. Also, resist the temptation of adding unnecessary parameters just for the sake of having more— it can do more harm than good.
Dedicate your attention where it’s most needed and keep everyone on the same page.