Bread & Butter: Backlog Best Practices

Many new PMs usually jump head first into their Jira board — it’s your bread and butter. We share some best practices when setting up the board(s) for your team.

Two simple things most PMs don’t immediately see:

First, it does not have to be one backlog that you’re curating. Instead, build an ecosystem of backlogs, each for a different purpose. Just make sure to keep an overview.

Second, you don’t have to manage your backlogs alone. You got designers, developers and ideally QA engineers who can all help with this — you’re a team after all. In fact, a sign of healthy, pro-active and highly independent teams is that everyone contributes and and takes care of the backlog.

Now, there is no golden rule to setting up your boards and backlogs, but here is an example that usually works for most teams in many tech startups — We call it the Batman Backlog:

Your Core (Story) Backlog

This is what people usually understand as a backlog. It’s the place where all our validated user stories live. This thing feeds your sprints if you work in SCRUM.

the 90–60–30 rule

When working in sprints, make sure that you already create and fill the next one or two sprints on your board while the current is ongoing. This provides a neat overview for everyone on what’s going to be worked on. Try to stick to the 90–60–30 rule:

• The upcoming sprint backlog’s tickets should always be at least 90% ready for development. If a couple finalizations on designs or a question on software architecture is still open, that’s fine. Just make sure to answer it before the sprint planning for this backlog. This way, you’re always a step ahead.

• The upfollowing sprint’s backlog should at least be 60% ready. So, make sure all user stories for an epic are defined and the epic as a skeleton is ready. Also low fidelity designs and user flows should be ready and high-level architecture scribbles should be done. Most of the teams effort should now be on defining the endpoints and request / response formats as well as creating high-fidelity designs and whatever other specs and resources you have to set to get towards ready for dev.

• The rest of your backlog should at least be 30% ready. The problem should be set and validated, the epic should already be filled with draft stories and first solution ideas which need refinement. These issues will be worked on in over a month, so it should be clear what to do and the solution just needs to be properly defined.

use themed sprints

Try to fill sprints with topics that belong to each other —via epics, for example — and don’t just push random tickets into them which are maybe equally important, but not necessarily related to each other. Your developers and designers will thank you.

a backlog full of problems

Last, but not least: Try to not to write your stories’ in the form of solutions, such as “Document Viewer Loading State”. As a PM it’s your job to come up with problems worth solving. And it’s your team's job to find the best solutions. If you write your tickets like solutions, you do not only narrow your team’s space to become creative and explorative. You also might miss-address the actual problem that needs to be solved here. Instead, try to formulate your epics and stories as problems, e.g. in user story format. For the example above it might be something like “As user who entered the doc viewer, I want to know if a document is currently loading, So that I understand the system works and is not broken”. I know, this ticket title is pretty long, and it’s strange at first. But thining this way will not only help you identify why you’re actually doing some things. Your closer overlap with the actual problem will open your team some space to become more creative. I’ll ensure you will be positively surprised.

Have a Refactoring Backlog 👾

Many companies ignore refactoring tasks until they pile up and become a daunting mountain of tech debt which basically leaves no chance other than re-building the entire application because no dev wants to touch the codebase anymore.

You don’t neet to have everything neat and clean — code can always be perfectionized, there is not end to it. But make sure to continually reduce debt on your way to ensure that the cost of maintaining your debt don’t significantly reduce profitability.

The easiest way to to this is to let your tech team curate a Refactoring Backlog, where they collect all the refactoring tasks, that slowly accumulate and where the team sees the need to at some point work it off. Regularly consult with your tech lead on the status and let her take responsibility over this part of your backlog.

Now, slip a portion of these tasks into every sprint, or — even better — declare every second or third sprint a “ops sprint” in which you only work on refactoring tasks. Not only your devs will thank you, but also your business numbers will show the advantages of not accumulating excessive debt when ignoring necessary refactoring tasks.

Have a Bug Backlog 🐞

Similar to the Refactoring Backlog, create a Backlog especially for Bugs. Ja, ja, I know… your teams don’t produce any bugs ;). But in case some might, this bug board is a handy tool to keep track of them. 

Also, it might help you deal with bugs in a more organized fashion. Instead of fixing any and every bug, be a little selective, particularly if you have a young product which is yet trying to find market fit. Quality is great, but you gotta make sure to also offer some functionality that actually solves your users problems.

If you’re lucky enough to have a team of QA engineers, let them take care of the bug backlog. They know best which bugs still need to be investigated and reproduced, which bugs are worth to go deeper and look for the root cause, which bugs are actual showstoppers for your users and which are barely noticable. 

Regularly consult with them and make sure to always fix a portion of your bugs in each sprint. E.g. set a threshold for each sprint and allow only a maximum of 15% of your story points in there to be bugs.

Bugs and Sugs

In case your QA team finds the time to pay attention to numbers and stats (and work well together with Customer Support in most cases), a well-curated bug backlog can also help you find (new) value opportunities. The main way you’ll validate a bug-related opportunity hypothesis is by looking for data about how big of an issue the bug is — i.e., how often does it occur and what impact does it have on the success metric? It might seem silly to explicitly list bugs as an opportunity to explore — if you’re an engineer, you’d likely prefer to have no bugs — but one of a PM’s challenges is to weigh the overall value of fixing a bug against that of not fixing the bug and doing something else instead. Quality’s always important, but not every bug is a high enough priority to go fix immediately.

… and a Hypothesis Backlog 🕵️‍♀️

Not all epics and stories in your backlog will survive the validation phase. They will be archived, deleted or worse, somehow still stick around and fall down the ladder of your backlog. 

This not only gives you a hint towards the necessity of regularly cleaning up your backlog and radically getting rid of all the tickets you haven’t touched in a while, say a month or so. It also advocated that maybe it’s not a the worst idea to also have a backlog of epics and stories which did not yet qualify to become future sprint candidates.

These are problems which you collected or ideas generated which yet need to be validated, e.g. through user research. Put them into a Hypotheses Backlog and let your design (and data science) team take care of it. If you have the luxury of having a User Researcher at hand, great. If not, any other Product, UX or UI designer will help you — least people in your company are as close to the user and have a unspoiled view on their needs as your designers.

Align closely with them and make sure to also take your developers with you on the occasional user test or interview. It will give your whole team a more sharpened focus on user needs.

The Icebox ⛄

So, long story short: An icebox is a list of requests and issues that nobody is going to work on. Low priority tasks, minor bugs, interesting ideas for “not right now”. So, actually an icebox is a ticket cemetary. Because, let’s face it: There are only two ways to deal with a requirement. Either it generates enough (user) value to have a high enough priority to be done —then do it. Else, throw it away.

But why then use an icebox? An icebox can be a useful tool nevertheless, if you get your expectations for its use case right.

If you got any ideas in your backlog which are interesting but just “not now”, or any tickets that are worth working on — you don’t just want to throw them away —  but have been lying there for more than a month or so, put them into the icebox. Make no mistake: You will probably never ever work on them. But it gives your mind peace to know that these tickets are not irretrievably lost, but rest somewhere safe and sound. This will help you be more rigorous in your decisions to weed out tickets from your actual story backlog. And if you are a nostalgic kind of person, feel free to have a look at your icebox next year — maybe you’ll find something interesting there to work on now or tickets of which you can get rid of now for sure.

Got questions, ideas or remarks on this method? Join the conversation on

Slack