Blog

How to Deal with an Ever-Growing Backlog?04 Oct 2016

If you're used to storing your workflow on a visual board, you may be experiencing the curse of a forever growing backlog column - in which case, you're likely thinking "we're never going to get this project done".
Chances are - you may be right!
Consider the odds of you actually getting to work on the last items of the list, if new items, often of a higher priority, keep piling up.
It's not uncommon for software developers to - sooner or later - just add another column or project, in which to keep the tasks they ARE going to take up in time, knowing all too well, the original, existing backlog has too many ideas they'll never get to.
It can be said then, that if the backlog overgrows certain size, it may just as well stop existing, because it becomes an irrelevant, "pie in the sky", "wouldn't it be nice" place for things no-one will ever get time to work on. So, what's the alternative, then?

Limits

One, albeit radical, idea would be to not let the backlog overgrow the team's capacity in the first place.
In other words, if the team can normally handle 40 tasks a week, put a 40-task limit on a weekly backlog. While you're at it, consider that it's - in general - worth putting a time frame (any time frame) on all backlogs. This is one logical way of ensuring things don't end up being written down and left idle for ages.
It's great to split planned work into backlogs of different stages of urgency and time-line: quarterly, monthly, weekly, subdivided into: urgent and of a secondary priority. This way the team know what to pick up when, and there is room for assuming that if we haven't gotten round to the items of secondary priority this week, they are to be moved to urgent next week or removed from the backlog completely.

Dimensions

The other thing you can do to keep tabs on the size of the backlog is to better organize the entire process you follow. Divide the work you do into more defined themes, epics, projects, product growth steps, stories, features, tasks. Having a hierarchical order of things that need / can be done will make adding priorities and tagging the ideas much easier. Note, that not all stages of the development need to make it directly to the working backlog.
Either set up a whole, granular order of backlogs, or keep the more general stages at another level of management (as a general time-line with an idea repository). Not every small thing you can think of for a project needs to make it to the actual project board. Does it?

Definitions

It's also important to define what you consider the backlog to be in the first place, before you begin your rework of its structure. Is this meant to be a list of things that are now decided that need to be implemented, or is this a list of loose ideas you're hoping to be able to get done? Unless you have this worked out, creating a backlog where items from both of these - very different - categories will get, makes no sense. It will only create confusion and add to the notion of leaving it be, as it offers too much choice and too little instruction.

Try getting a grip on the actual things you're going to work on by applying a new backlog policy or by splitting it into a few sub-divisions, like on this Kanban Tool board:

Your team will not know what's what, unless you make it clear to them. Try it out!