Since publishing my article on how to organize a large product backlog, I got a lot of questions from readers that wanted more details on the workflow and how to set it up in Trello.
That’s why I decided to create a set of template/example boards that you can copy to your own account and tweak as you wish, as well as a sort of FAQ from a couple exchanges I had with readers.
If you haven’t yet read that article, I recommend you do, as a lot of things in this one assume that you’re familiar with the ideas it put forward. Anyways, here’s a quick recap:
- We create a problem for ourselves by thinking of and managing our backlog as a list of items;
- We’re better-off if we think of it as something with 3 dimensions:
- The work to be done — the set of things that need to be accomplished;
- The product areas we’re working on — we’re usually working on more than one, and looking at work as a single list in these cases becomes a problem pretty quickly;
- The granularity of visualization — an initiative on the roadmap has multiple epics and each its own user stories, but they all refer to the same thing, they’re just at different levels of detail.
- We can create a Trello workflow that supports these 3 dimensions to keep our sanity whilst managing a large product backlog.
The Trello template
This workflow and set of boards is heavily inspired by the one used at UserVoice (albeit simplified), and I encourage you to read that article as well.
Conceptually, this is how the Product Backlog can be thought of:
At each level, priorities go from left to right, top to bottom.
This structure can be reflected by 3 main boards: Roadmap, Epics and Kanban (the development methodology we use.) Each represents a level of granularity. Each also shows the scope of work at its level, and the priorities among product areas (or timeframes in the case of most roadmaps.) Here are the links:
Besides these functional views of the product and its backlog, there is also the technical view the development team has. It’s useful to keep an Engineering board for this and it can be considered part of the backlog, as it’s the reference for technical debt items and other engineering tasks. Here’s the link to it:
- Engineering board
Finally, it’s also crucial to keep a Sandbox board to store all sorts of product ideas, internal requests and still not validated features. This board is not part of the backlog but it’s critical to keep the noise out of it:
- Sandbox board
Go ahead, explore them and copy them into your own Trello account so you can tweak them.
In these examples, we’re managing a photo service with a backend, mobile apps and web frontend. Specifications and user stories are far from exhaustive (it’s just a very relatable example domain). The idea with these templates is to show you how the different pieces fit and how you could adapt them to your own team.
Some notes to consider when exploring these boards
- Each board contains a card named “About this board” at the top of their first lists. It contains more information about the board and how the different lists could be used — it’s additional information to this article as it makes more sense for it to be shown in context;
- Look how you can link from cards on different boards and thus navigate down from the Roadmap to the Epics or Kanban boards;
- Notice the sort of metadata on cards that can be used and where it might make sense for you. Trello has labels and they’re useful but I’ve found that it’s often necessary to add text tags as a prefix
- See how not everything is on the Kanban Dev Backlog — this is very important and the whole reason to have an Epics board. Stuff should only be on the Dev Backlog if they’re high priority and will definitely get picked up. This keeps the final backlog small and makes it easy to prune if higher level priorities change;
- Although we’re using Kanban, it’s not necessary for this kind of organization to work; the main goal is to provide different levels of analysis and to avoid managing your backlog as a simple list.
Common questions around this workflow
Over time I’ve gotten some questions surrounding this workflow that make sense to share here. I’ll keep this list updated as new ones come up.
How does engineering time get prioritized between Kanban & Engineering?
Negotiation. Say I’m pushing for some new feature, the team will then tell me if we need to work on some tech debt first. Sometimes it may also come directly from the team during our daily meetings: “this area is becoming / can become a problem due to our growth. We should address this.” As PM, I will then try to understand the issue and give the go-ahead in terms of priorities. It all depends on the situation but we trust each other and make sure that everyone’s on the same page regarding the tradeoffs of doing or not doing something at some point in time.
Do you prune the sandbox?
Yes, every once in a while. But less than I should 😉
Do bugs flow into your sandbox?
Only if they’re low priority. If they’re high priority, we actually keep an Inbox list on the Kanban board, that I use to sort anything the development or support team identifies. From there it goes directly to the Kanban Dev Backlog, to the Sandbox, or added to some Epic on our roadmap (some new requirement that was found.)
The official backlog is composed of the Roadmap, Epics, Engineering and Kanban boards. Any other supporting boards are out. All of what I’ve explained is in flux and we keep tweaking it as we go along. But the basis has been this for some time now, with great results.
Do you have to check off items in the roadmap or is that automatically updated when items get moved in the kanban board?
Yes, I have to check them off manually. I tried looking at Zapier or IFTTT integrations, but none had the triggers I needed (something like: "when a card gets moved to another list, check the checklist items where it’s included.) For now, it’s just a manual task I do periodically as I follow up on the status for each work item.
What columns do you have in your Engineering board?
The Engineering board is managed by the team. Columns usually are technical areas of the product, and cards represent work that should be done on each, or that they’d like to do sometime. They are also prioritized as they see fit.
Our design team usually works as a “shared resource” among all product teams in the company. They have their own board for all requests from all teams. I have to make sure that whatever is needed from them is ready before actual development starts. I coordinate with them, working through wireframes and mockups together
When actual development moves forward, there’s of course some communication that needs to happen between the Dev and Design team, but that goes on “our” Kanban board.
What about research/analysis tasks for PM?
I usually work off Todo items I keep in Things or from Sandbox cards.
What’s the purpose of the Blocked list?
It’s there to show stuff that is blocked on third parties and action should be taken by someone. Having it visible forces attention to this problem and that why it’s placed after the Backlog and before the In Progress board. On our daily meetings, we review each blocked item and check if it’s ready to be worked on again. When it is, it should be higher priority than anything on the Dev Backlog.