It is easy to get lost in all the feedback that you are exposed to from different stakeholders. There seems to be no bottom in the "wishing well" for new features. Filling up your backlog is easy, but it won't serve a purpose unless you are also actively refining it.
A well-refined product backlog helps you to focus on what's most important right now, while not ignoring what has been suggested by others.
There’s no shortage of tools for managing your backlog, but you don't really need anything fancy to start tracking your tasks - a simple tool like Trello can do the job. Here's how we use it to manage our backlog.
We have two boards that we use for tracking our tasks - R&D and Icebox. The R&D board contains all the work that we have somewhat committed to implementing within the next 2-3 months. For us, that’s pretty much the maximum that we can plan in advance. It's not a strict plan though as there's always new tasks appearing, and some tasks are moved back to Icebox - or simply deleted. But that's nothing to worry about - we don't feel guilty about changing our plans to incorporate new learnings.
This is what our R&D board looks like (click to enlarge):
Priority is defined by the ordering of the cards. The ones on the top are considered to be of a higher priority than the ones closer to the end of the list. Everyone on the team is free to move cards, and even create new cards. However, it's the Product Owner's responsibility to keep an eye on the board, and to steer priorities when needed.
Our Release backlog list contains 20-30 tasks that we have decided to implement in the near future. This list, like all the other lists, is evolving, so cards are added and deleted. But this is the list that has the cards that are most likely to make it to the product in the near future. This is also the primary source of new work when a developer runs out of tasks.
Every two weeks we have a planning session in which we move the highest priority tasks from the Release backlog to the next iteration. At this point cards should have requirements specs and design mockups attached to them so that developers can start their work without delay.
Your backlog should be visible to all stakeholders so that that there are no surprises when it comes to what will be implemented next. If you have a task that’s been on backlog for more than a couple of sprints, consider moving it to icebox.
The Icebox board consists of tasks that we may want to promote to the R&D board at some point of future. It is a home for all those ideas and low-priority features that we want to keep but which do not require our immediate attention.
That's a lot of cards! There's never a shortage of new feature requests as it's always easier to come up with new ideas than to actually implement them. But still, this is an invaluable resource to have when choosing what to do next for your product. This is the place where we keep a record of all feature requests from our customers. Each request is considered a vote, and the cards are ordered according to number of votes in them. Once a card gets enough votes, it's promoted to the R&D board for implementation.
Our Icebox board consists of these lists:
- UI improvements - Pixel tweaking and other UX-improvements
- New screens - Ideas for new dashboard screens
- Content creation - User guides, help texts, blog posts and other copywriting
- Feature requests from customers - All feature requests from our users
- Non-urgent bugs - Bugs that don’t require immediate action
- Technical - Refactoring and other backend functionality
- Trash - Tasks that have been suggested for removal
There's a real threat that an extensive icebox like this becomes a junk yard of tasks that never get implemented. Therefore, it's important to prune it periodically by deleting the cards that no longer seem relevant. Your icebox should be somewhat stable in size, not ever expanding.
Don't worry so much about accidentally deleting something important - if it's important, it will be suggested again. If not, then perhaps it was meant to go. The phrase 'less is more' applies to backlog management as well.