How to Deal With an Ever-Growing Backlog
One idea - as radical as it sounds - would be to simply not let the backlog overgrow the team's capacity in the first place.
Join the DZone community and get the full member experience.Join For Free
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 that they are going to take up in time (knowing all too well that the original, existing backlog has too many ideas that 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?
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 that 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 timeline: quarterly, monthly, weekly, subdivided into urgent and of a secondary priority . this way the team knows what to pick up when and there is room for assuming that if we haven't gotten round to the items of the secondary priority this week, they are to be moved to urgent next week or removed from the backlog completely.
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, etc. having a hierarchical order of things that need to or 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 timeline 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?
Published at DZone with permission of Anna Majowska, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.