8 Different Ways to Organize Your Backlog to Make it More Impactful
Linear backlogs are so yesteryear
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?
Jeff Patton was one of the first people to challenge the notion of a linear backlog when he created — and then wrote the book — User Story Mapping (more on that later).
But really a linear backlog typically isn’t usually a bad thing, especially not at the beginning of the product lifecycle — when the product was still in its infancy and likely the team was small. Your number of users were limited to a few and functionality was quick simple and as a result, your product backlog likely only had but a few items in it — ahhh, these were the glory days!
Over time, assuming your product was successful, the product starts to grow in complexity — features are added, users are now in the hundreds of thousands, perhaps millions — and now your backlog is starting to look a lot like my morning coffee queue in the middle of peak hour. The problems you are trying to explore and focus on are now numerous and the different types of items (often referred to as “classes of work”) in your product backlog now outnumber the total items it once had! — from defects, UI enhancements, problem spaces to explore, new innovative ideas to try out, experiments, new features, optimising current features, technical debt, security, etc — the list goes on.
Staying on top of all this is the work of a superhuman, which we are unfortunately not. This is why backlogs start to be given titles like — “the place where ideas go to die.”
Revisiting how your backlog is organised regularly is a must — a practice of good backlog management in my experience. Consider your current context and whether your current backlog structure is fit-for-purpose? — it could make the difference of your backlog becoming a dumping ground or dead ideas and an effective tool that powers your product.
So, here’s 8 different ways to structure your backlog to spark your inner creativity and overcome any backlog-blues you may have.
1. User Story Map
Perhaps the most popular non-linear backlog of them all — the User Story Map — created by Jeff Patton and propelled into stardom, his book User Story Mapping is a must-read for any Product Manager!
So rather than having a linear backlog, Jeff proposed building you backlog around your user — more specifically your user’s journey and how the product supports their journey to achieve specific tasks and goals.
My personal favourite benefit that you get from representing your backlog this way is just the holistic view you get of your entire backlog and where each item sits and how it contributes to a JTBD (job-to-be-done) in a customer journey.
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.
2. Idea Funnel Backlog
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.
You can break your funnel up with different phases or you can treat it like a roadmap (even a simple ‘Now-Next-Later’ works really well). The funnel backlog is a roadmap and backlog in one — a roadmap-backlog — and the best part is rather than maintaining two artifacts you only have to look after one!
3. Opportunity Backlog
Another one from Mr Jeff Patton and one which is popular when running his “Dual Track” approach.
In the Dual Track world, you split your backlog into two — one for delivery and one for discovery. This is where the Opportunity backlog comes in, it’s your discovery backlog. All the ideas, problem spaces, and opportunities are thrown in here, if validated as a good idea they graduate to the delivery backlog, this is where things move from the problem space into the solution space and we eventually build it, ship it and then learn from it. And eventually the learning will lead to more opportunities and thus making it’s way eventually back into the Opportunity backlog and that’s the circle of Product Development!
4. Classes of work
One of the things that the above Opportunity backlog is doing is essentially breaking your backlog up by classes of work. Often I find the Product Managers that I work with are already doing this through some tool — often tools like JIRA, etc allow them to tag items, create different types or even attach labels.
What often happens over time is their backlog grows and to keep track of everything they have to go labeling-crazy and tag the crap out of their backlog. When you think about it what they are actually doing is dividing their backlog into multiple smaller backlogs based on different classes of work — we have a tech debt backlog, a UI enhancement backlog, a feature backlog, etc. whilst no inherently bad to use labels to achieve this, there are other ways to represent your product backlog, and you don’t need to go label-crazy on it.
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.
5. Tree Backlog
The growing complexity of technology and being able to visually represent the inter-relationships and alternative paths to a feature, saw the creation of the Technology Tree.
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.
The best use of the tree backlog I’ve ever seen was recently an Australian neo-bank called Up made their roadmap public — and it’s fantastic! Interactive and visually beautiful!
Another popular ‘tree’ backlog approach is for organising your Opportunity backlog. Created by Teresa Torres, Product Discovery extraordinaire, she created what she calls the Opportunity Solution Tree, a very powerful way for teams to visualise and think about their discovery work — check it out! It’ll change the way you do and think about product discovery for the better!
6. Impact Map Backlog
Similar to the Technology Tree, impact mapping works in a similar way in the sense that it branches out. However, unlike the Technology 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.
Impact maps are great for ideating many alternative paths towards a particular outcome. 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.
7. Circle Backlog
Sometimes you’ve just got to get creative! And that’s exactly why I love the Circle backlog!
There’s just something about breaking the mold — or perhaps it has to do with the lack of corners — that brings the creativity out in people. I’ve seen all kinds of out-of-the-box ideas when it comes to a circular backlog — dartboards looking backlogs, even spiral’s where backlog items gradually spiral towards the middle!
Circle backlogs are perfect for creating ‘slices’ to categorise your work whilst still maintaining a holistic view in one place — you can even get creative and have different slice sizes, a great way to physically restrict WIP!
Circle backlogs are great if have multiple backlogs feeding into one or want to categorise by feature, epic, theme, school, classes of work, etc. And much like the Funnel Backlog they also can act as a roadmap + backlog in one.
8. Conversion Funnel Backlog
This is my favourite type of backlog when it makes sense to do so. For products which have clear conversions, say an e-commerce style product, then structuring your backlog around your conversion funnel(s) is ideal. This 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.
I’ve always very much enjoyed working with this kind of backlog because it makes prioritisation a dream! 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.
Conversion Funnel backlogs are great for early and growth stage products as it gets you focused on key factors such as conversion, retention and referral. But they can also be powerful for more mature products where tweaking is needed. Often backlogs grow-and-grow, becoming bottomless and a nightmare to manage. This is where Conversion Funnel backlog can help as the focus on a particular point in the funnel takes you from trying to prioritise 200 things to 10 things — much easier!
What other ways have you represented your product backlog?
**Update**
Many have asked how I have done these backlogs, they were created using Miro.
In fact, Miro have been so awesome they reached out and as part of the launch of Miroverse we have turned this into templates for you to use —which you can find here: 8 Different Ways to Organize your Backlog — Miroverse
I’ve also had a few questions about Jira, I know many use it. Miro has a Jira integration so you can easily manage your backlog in one of these structures from Miro and still manage team sprints/tasks from Jira — it works really well!
