The best way to think of filtering the Product Backlog is to imagine it -or actually have it- in a spreadsheet and apply a condition that will display only the rows that meet that condition hiding the rest.
Filters can provide views of the Product Backlog without necessarily changing priorities. In fact, by seeing just a portion of the Product Backlog that meets certain criterion we might discover that we need to reorder the Product Backlog by changing priorities.
Organizing items in the Product Backlog around certain characteristics is another form of filtering, for instance we might decide to organize the backlog putting high risk items first.
By ordering the Product Backlog we may change priorities or just do something more temporary like applying a filter for visualization purposes only. Next you’ll find two techniques that can be really handy for organizing and filtering a Product Backlog.
Specific user/customer types
Which basically means filtering all items that a particular user/customer will use; in other words, the filtering criterion will be user/customer type. An example of this could be having a Product Backlog for a product similar to Uber in which you filter by driver or by customer.
Feature areas
In this other techniques the idea is to filter by observable functionality that end users would be able to use and interact with. In simpler terms, the filtering criterion will be the feature area name that represents functionality. If we take the Uber app example again a feature area could be “Request a Ride” that has a lot of backend functionally but more importantly is directly observable and has great value for end users.
One last reflection, both techniques can be combined to narrow down the displayed items, for example we could filter the Product Backlog to only see items that correspondo to the feature area “Request a Ride” and that will be used by the “Driver”.
