9

Organizing a Large Product Backlog

Trying to organize a large product backlog is a tough thing to do. As times goes by, and the product grows, what was once a simple list of prioritized items gets unwieldy.

Working from a huge list makes it very difficult to navigate and very easy to get “lost” in it. You lose track of what’s going on, what should come next and what’s really low priority. Duplication abounds. None of this is helped by the fact that the backlog keeps growing: as higher priority items get done, new work is added and older items accumulate further down.

A self-inflicted problem

We’re creating problems for ourselves through the amount of stuff we put in the backlog and by structuring it as a list — let’s go over each of these.

First, there’s our tendency to keep everything on the backlog. Every idea, request, bug, maintenance chore, user story, you name it — gets included. We say to ourselves that we can always groom it later on (but we don’t.) We’re also not helping when we use the backlog as the standard (non) answer to requests from stakeholders — “sure, I’ll put your <pet feature>on the backlog and consider it for <some future release>.”

Then, there’s the issue with how we structure it. We gravitate towards a list probably because of Agile methodologies, or maybe because that’s the natural way to think about work to be done. The thing is that although the team can work off a list on a given sprint or release cycle, it’s a terrible format to manage the multi-dimensional beast that is the backlog.

Proposing a Way Out

Having established the two main reasons that lead us to a chaotic backlog, it’s time to discuss how we can avoid these pitfalls.

Adding Dimensions for a Richer Structure and Navigation

The backlog is a prioritized store of work to be done on the product, but if we are to overcome its List form, then what shape should it take?

Story mapping is a great approach, but I think it works best for well defined projects that won’t be subject to much change in scope as you build them. When you’re working on a product with an ever-moving scope, going into such detail is probably wasteful. On the other hand, this sort of multi-dimensional thinking is definitely the right way to imagine a backlog.

We can start out by considering a large product backlog to be something that has both Length and Width:

  • Length refers to the amount of things to do (and the classical list shape);
  • Width refers to the different product areas, modules or initiatives it encompasses. It’s any way you can group a set of interrelated items.

These two dimensions are common to backlogs of any size. Even if you’re working on a smaller product that may not be Wide, it can still be Long — the analogy still applies, it’s just a simplification.

Being a backlog, it’s important that each of these dimensions is prioritized: just as some items have higher priorities than others, the same can be said for some product areas and initiatives vs the others.

Product Areas vs Work to be Done

Combining these factors is a great step forward in creating something that is easier to navigate and understand, but it’s still not enough:

  • It is too low level for us to create (and track) our roadmap, as we need to know which initiatives and features will be released over time;
  • It is too high level to use as our actual development backlog, because at the end of the day we do need a single prioritized list for our team to develop.

To help with this, we need to add another dimension: Depth. It will represent different levels of granularity in how we look at our backlog:

  1. The high-level initiatives/themes/epics we’ll be working on “Now”, “Later” and “Next” 1;
  2. Breaking down each initiative/theme/epic into lower level items and user stories;
  3. Individual user stories and tasks that end up on our actual development backlog.
Work vs Areas vs Granularity

Having this rich structure for our backlog should enable us to slice and dice through it much more efficiently and effectively. (In case you’re wondering how this translates into practical terms, I’ll describe how you can set up this type of structure using Trello in just a little bit.)

Keeping it Lean

Having a fancy 3D view for our backlog is not enough. As we saw before, we also need to control what gets on the backlog and how long it stays there.

Think of the backlog as the set of things that you believe should end up on the product in the very near term. Anything else should stay out. Don’t be a backlog hoarder.

Every input, idea and feature request you get from the outside world(customers, executives, other teams, etc.) should end up in some sort of “waiting room” or DMZ. It should never go straight to the backlog. After you’ve validated that it’s actually useful and/or important, then go ahead and include it.

Also, any items that have been waiting to be done for more than 6 to 12 months, should be ruthlessly archived or sent back the waiting room. If they clearly aren’t important enough to be done, then they definitely don’t belong on the backlog.

A Real-World Workflow to Keep an Organized Backlog

What I’ve described so far doesn’t need to stay theoretical. You can setup this kind of workflow using Trello 2. Here’s how we do it:

  • Our team follows a workflow heavily inspired by the one used at UserVoice;
  • We keep 4 main boards:
    • Roadmap — it contains 2 or 3 lists, each representing the epics we’ll be working on over the next 2 to 3 quarters 3. Each card on each list is an epic. Within the list corresponding to the current quarter, each card contains checklists with items pointing to cards in the following board (we don’t go into such detail for epics on future quarters);
    • Epics — contains lists for each epic we’re working on in the current quarter. Each list contains the specific user stories and tasks that compose that epic;
    • Engineering — this board is owned by the team and contains tech debt and other architectural issues the team identifies as they move forward;
    • Kanban — contains our Kanban workflow, with lists representing each step in our process. There’s a single development backlog list, which is fed from the Epics and Engineering boards, after negotiation between the team and myself.
  • We also keep a supporting board called Sandbox — it is where we keep every suggestion and feature request we get. It’s not considered to be part of the backlog;
  • The final development backlog is usually kept short, with few items in it. The goal is to avoid having to send back items to the Epics or Engineering boards if priorities change. Ideally, only items we’re completely sure will get done end up there;
  • I routinely groom the Roadmap and Epics boards, as priorities change;
  • Every once in a while, I check the Sandbox for ideas to validate and possibly include on the Roadmap;
  • Any card that stays on a board for more than 6 months or so, gets deleted or sent to the Sandbox.

This workflow isn’t perfect and we keep tweaking it over time. In spite of that, it has proven to be a strong solution to organize and navigate a very large backlog.

How about you? How are you keeping your backlog organized? Go ahead and leave a comment below or email me.

  1. You should really check out this presentation on roadmapping by Janna Bastow (of Mind the Product and ProdPad fame) 
  2. If you haven’t yet tried it or have been living underground, Trello is a very flexible tool that you can shape into a lot of different workflows. It’s also a particularly well made piece of software. 
  3. Despite Janna Bastow’s very wise advice to avoid dates on roadmaps, our team can’t avoid them due to stakeholder pressure. To counterbalance this, we work in the broadest date terms we can: quarters.  

Enjoyed the article?

Get actionable, useful content and resources on Product Management. Delivered straight to your inbox for free. You will also get in-depth guides to:

  • 20 Product Prioritization techniques (44-page PDF & cheatsheet)
  • The Kano Model (40-page PDF & spreadsheet)
No spam, ever. Unsubscribe at any time. Powered by ConvertKit
  • Good article. One other tip to add to Janna’s about limiting the loss-of-flexibility that comes from committing to dates: Commit to value (or user goal achieved) on date X. Don’t commit (if possible) to design approach Y, or by any means features Z1, Z2, Z3.

    Leave yourself the latitude to change design approaches, deliver incrementally (incremental sets of users or incremental realized value for any given user), etc.

    Another benefit of this approach – when having the expectation management / scheduling discussions, if you try abstraction like this, you get extra data from stakeholders about the precise value (to them) of whatever problem you’re solving.

    • Daniel Zacarias

      Thanks Scott!

      That’s a really great suggestion. The trick there is getting the autonomy to commit to values/goals and not to specific approaches. Stakeholders often need to feel part of the process and insist on signing off on the exact thing that should be built… and that’s a whole different problem I’ll get to on a future article.

  • Pingback: User stories resources | Technology Unplugged.()

  • Daniel – like this approach a lot. I have also used another approach in the past (this was with Accept360) where the backlog is really just a bucket of everything we could do. The way you find stuff in the bucket to *actually* do is to use meta-data like the theme or themes it addresses, the customers who want it, the competitors it helps us differentiate from (or meet), and so on. Then, when we have a business strategy to a) address themes X, Y, and Z, and b) make sure customers P, Q, and R are happy, and so on, simply use those criteria to pull items from the bucket. Then you select the top candidates according to how well they align with the strategy, compared that to how costly they are. (Well-aligned and cheap is a no-brainer, although usually things cost commensurately with the business value they enable.)

    Essentially we turned a list management problem into a search problem. Not that there aren’t myriads of challenges with this approach as well, but it *felt* fundamentally correct – explicitly using the business’ objectives to drive prioritization.

    • To pile on, I also agree that this “feels right” – at least when I’ve worked with teams where we were able to do this too.

  • Mickis Odlander

    Hi, can you get the 3D image of the backlog from Trello?

    • Daniel Zacarias

      Hi Mickis

      That would be cool, but it’s not a feature. That 3D representation is just how I think of it when I navigate it.

  • Lenae Boykin

    This is really great and something that I’ve been discussing a lot with my team. Especially as it relates to the multi-dimensional relationship of tasks, stories, epics, and overall problem solving. Something that I was hoping to understand from this article was how you can structure that lifecycle and dimenstion as stories move from high-level into specific via the development backlog. I know you mention Trello, and I have used it before with other dev teams, but my current team uses JIRA heavily. And with JIRA has come the ‘list view’ in which I just cannot confidently priortize and strategize the work we’re doing. Do you have a suggestion for a workflow that includes a combination of JIRA?