Tag: Product Backlog

Keep the Backlog at a Manageable Size 

A Product Backlog with hundreds of items clouds visibility and demoralizes the team that can not clearly see the light at the end of the tunnel. What is even worst the cost of maintaining a huge backlog is so high that consumes the Product Owner’s time preventing her/him from working in more important things.

For the reasons stated above is very important to keep a backlog with the least number of items possible. Empirical evidence from several sources including my own experience show that less than one hundred items seems adequate. 

Be Proactive and Groom it

The Backlog Refinement Meeting is an event specifically designed to keep the backlog away from growing unnecessarily and with the wrong level of detail. This event an other mechanisms should be used to keep the backlog in good shape and as a valuable artifact for the team. 

Making an analogy with gardening, grooming is an essential activity that needs to be performed weekly or bi-weekly at the most, if not plants and trees grow wildly and eventually the whole garden ecosystem starts to degrade. Not grooming the backlog will cause the same effect: degradation. 

Share the Backlog with Stakeholders

Having stakeholders input about the backlog is very valuable because it helps the team to gain reassurance if they are building the right product with the right features. From the stakeholders perspective it’s very valuable to learn if the team is correctly interpreting their needs and concerns and crafted a possible solution that is being represented in the form of backlog items.

Trying to share the backlog with stakeholders will fail if communication is not effective and for this high bandwidth communication like face to face dialog is always recommended. Avoiding concussing terminology in the communication is another recommendation.

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”.