How to Organize a Backlog ?

Product backlog is really the barebones of agile scrum teams. It help Product Owner to communicates vision to stakeholders, it help dev team to anticipate future needs and adjust design accordingly and it help Scrum master analyzing how team can be more efficient in its work.

Unfortunately, backlog is often a mess filled with “could be useful” ticket , “will never be fixed” bugs and other “I got this idea the other day when taking a shower” stories. We will see in this article some tips to help maintaining your backlog clean and focusing on what really matter.

Addressing stories

I won’t detail the different level of Program/Initiative/Epic/Story here. I’ve always been closer to production team than marketing team, so I have not so much experience regarding Epics or Program ticket level. Lets just assume a story represent something needed by a user that can be implemented in less than a few weeks of effort by dev team. As we are in an agile environment, user require this feature now and will certainly change its mind in a few month. So this story should be addressed quickly to be valuable for our user, and as a consequence, for us. This lead us to the first statement:

A story is not a long term vision.

Story should be addressed in the next few months, in current or next quarter. A story planed to be addressed in a year has lot of chances to be obsolete and no more adapted to user need, and just pollute backlog during months with useless information. That’s why Product Backlog should only contains the detailed stories for the next 2 quarters at worst.

— Yeah, but I have lot of important ideas !

That’s cool ! But, either your ideas are priority for next release, so they are in backlog, either it’s just some good ideas but not required for next releases, in this case they should not appear in backlog to avoid drowning important stories.

— Yeah, but I want to keep trace of it !

Yes, I know it’s very critical to keep trace of those 2 minutes cogitation you had during your breakfast… You then have 2 solutions:

Solution 1

you really want your team to spend time on it. You want to spend money refining this idea, having a rough estimation of its efforts and its ROI but you are still not ready to plan it in a release. You can store it in something called a “Funnel”. It can be a completely separate backlog like Productboard, Aha, a dedicated Jira board or even lighter tools like Miro or Trello. It can also be a filter in main backlog to hide these story by default. Once you find this story valuable enough, you can move this ticket to product backlog and really refine it in order to implement it in short term.

Solution 2

Your idea is just an idea. You can talk about it during coffee time, takes inputs, etc… but keep it in your own PO’s TODO list until you consider it important enough to be placed in Funnel.

Remember, the more stories are in backlog, the harder it is to focus on what matter.

— And what about stories that were top priority at some time but were canceled because of reasons ?

As you said. They were canceled. So stop lying to yourself. Either you will do it, either you won’t. Either you implement it for next release, either you remove it from backlog to focus on what matter. You can put it into Funnel or completely cancel it. Cancelling a story in Jira or any other board does not delete the ticket, it is still somewhere and can still be reopened in the future. (Spoil: this will never ever happen…).

Addressing bugs

Stories are ticket that should be planed in short/middle term depending on their ROI. Bugs should be handle differently, more like a continuous flow. You can stop the flow of story. You decide to open or close the faucet. You can close the faucet and stop any activity if you want. Unfortunately, you cannot do this for bugs. Bug flow is controlled by user. And if you are falling behind to fix bugs, they will pile up and overwhelm you.

As a rule of thumb, put bugs in top of backlog so that they will be addressed in next sprint. Do not be tempted to accumulate bugs to do a “stabilization sprint” just before release. By “address”, I don’t mean “Fix”. To address means giving a solution to user. You can fix it, you can find an acceptable workaround, or you can purely cancel it considering bug is too costly to address. You would be surprised by the amount of user who can accept a bug if you explain them gently why it cannot be fixed. And you would be even more surprised by amount of user that would find a workaround as valuable as the actual fix. Finally, handling bugs in backlog can be summarize by:

– Bugs are top priority.
– Either you fix it, either you close it.

That’s theory. In practice, I encountered a case where it was a better idea to accumulate bugs and fixing them by bunch. It was an old C++/COM legacy software. Deploying a dev environment required a day or two, copying file here and there, setting environment variable, downgrading to an old Visual Studio, etc… There was no activity on this product anymore but we still receive some bugs from time to time. In this case, we agreed to spent a “bug fix sprint” once or twice a year to fix all bugs at once and release a new patch.

What about long term vision ?

We just saw that product backlog should gives a few months, maybe a years of visibility, no more. But How do you share your long term vision ?

You don’t share a vision with tickets. You share a vision with discussions and with coherence on what you do day after day. If you put in backlog stories that don’t have any link to each other, no one will understand where you want to go. If you put stories that Tell a story, a common thread will emerge and people will understand your vision.

What about the past ?

Backlog is NOT an overview of all the thing that was asked one day by some customer. It is NOT an overview of all the missing and broken stuff in your product. It is an overview of what you are going to do in the next months. So stop archiving every single request in the backlog.

In the end, what does a clean backlog look like ?

A good theoretical backlog look like this :

Backlog is alive. Priorities can be changed and stories can be cancelled at any time. But the idea is to keep good visibility in short terms by having well defined stories on top and have a rough idea of what is going middle term with stories to be refined at the bottom.

Remember: The Backlog is not a tool to show everyone all the great idea you have for your product. It is not an archive of everything your users have ever asked for. It is a tool to focus on what is important. The hardest part of a PO’s job is not overfilling backlog. It is on the contrary to keeping it short and valuable.