Often we don’t question our product backlogs, they’re a list of stuff we hope, might and would like to do, but do they always have to be represented as a list?
Backlog as a User Story Map
User Story Maps are a great way to quickly build out your backlog for the first time, it’s also a powerful tool for release planning.
For more mature products I’ve often split my user story map by customer archetype, JTBD, objectives and even problem spaces, depending on what makes the most sense.
Idea Funnel Backlog feeding into a Kanban board
Literally a funnel! A great way to visualise your backlog and to actually physically restrict the number of product backlog items that are at the “top” (well “right”) of the backlog.
This form of backlog is great to help with prioritisation and focus whilst also keeping things fluid without too much overhead or formal structure.
Splitting your backlog into two — Opportunity backlog for discovery and Development for delivery.
All the ideas, problem spaces, and opportunities are thrown in here, if validated as a good idea they graduate to the delivery backlog.
And eventually the learning will lead to more opportunities and thus making its way back into the Opportunity backlog and that’s the circle of Product Development!
Divide your backlog into multiple smaller backlogs based on different classes of work.
What often happens is that in order to keep track of everything product managers go labeling-crazy. When you think about it what they are actually doing is dividing their backlog into multiple smaller backlogs based on different classes of work.
One simple thing to do is to literally separate them. Most tools will allow you to achieve this using different views and filters whilst keeping the integrity of a single view for things like your sprints.
Tree backlogs are great for complex products with many different feature sets.
Technology Trees are great for complex products with many different types of features. Representing your backlog in this manner is a great way to visually show how different features inter-relate and how certain functionality can start out simple and incrementally be enhanced.
Impact maps are great for ideating many alternative paths towards a particular outcome.
Impact mapping works in a similar way to the Tree Backlog in the sense that it branches out. However, unlike the Tree each stage in the branch is not another backlog item rather it represents a stage in the impact map moving from the WHY > WHO > WHAT > HOW.
Representing your backlog this way is great for keeping everything outcome orientated. However impact mapping backlogs aren’t great at representing other classes of work such as technical debt, bug fixes, etc.
Circle backlogs are perfect for creating ‘slices’ to categorise your work whilst still maintaining a holistic view in one place.
There’s just something about breaking the mould — or perhaps it has to do with the lack of corners — that brings the creativity out in people.
You can even get creative and have different slice sizes, a great way to physically restrict WIP!And much like the Funnel Backlog they also can act as a roadmap + backlog in one.
Conversion Funnel backlogs are great for early and growth stage products with clear conversions.
It brings two important pieces of information together, the quantitative data around drop-offs/potential pain-points in your funnel but also the backlog items/opportunity areas.
If there is a clear drop off at a particular point then everything within that section of the backlog is now your top priority. You get laser-focus, and you keep focusing on that section of the backlog until the numbers improve or if you get another compelling reason to focus on something else.
Do you have a great board to share with the world? We'll help you turn it into a template to share with the community.