Why Having a “Backlog” Sucks the Life Out of a Project
Do your developers work against a “backlog” of tasks? If you practice Scrum, Kanban, or some other variant of agile development, then you probably have one or more “product backlogs”, plus an “iteration backlog” for each team. Right?
I’d like to suggest that you toss out your “backlogs.” — And I mean that in two different ways.
First of all, let’s consider the word, Backlog. If you think about it, it’s a rather depressing term. For one thing, it implies that everything on the list is a must-have, when, in fact, rarely any of it is. For another, it implies that everything on the list is already overdue (“backed up”). In both cases, the mere existence of a backlog makes it sound like there’s a problem. And, where there’s a problem, there’s gotta be a culprit, right? So, the further implication is that those bloody slow engineers are always to blame.
In Greek mythology Sisyphus was a king of Ephyra (now known as Corinth). He was punished for chronic deceitfulness by being compelled to roll an immense boulder up a hill in Hades, only to watch it roll back down. He had to repeat this action forever in eternity. Engineers usually love their work, but not when it’s made to feel like a Sisyphean task. What’s the reward for getting that boulder to the top of the hill? “Oh, look! Another boulder.”
So, here’s some suggestions for better names I’ve seen used:
- Wish List
- Opportunity Queue
- Pullable Pile
- Story Stack
- Fridge Door (as in index cards stuck to a refrigerator door with magnets)
Your team can undoubtedly come up with an even more appropriate name.
Yes, this is all merely semantics, but it’s important in two ways. First, it goes to the morale of the team. It deemphasizes the dread of a weighty, still-pending backlog and instead emphasizes celebrating the completion of a ticket for what it’s worth — something that allows the business to take advantage of an opportunity. Second, that change in emphasis fosters better communication between stakeholders and engineers. It reiterates the values of being agile, from iteration to iteration, taking advantage of whatever opportunities make the most sense in the moment, rather than sticking to some preordained list of so-called requirements.
Okay, now let’s talk about pitching the backlog, itself, in the trash — parts of it, anyway. Maybe even most of it.
In my experience, 50-70% of the tickets in a typical backlog are pointless distractions. All they do is get shuffled and reshuffled. They never come to fruition because something more important always comes along. So, they just end up wasting everyone’s time by getting in the way.
- So, first off, kill all tickets that you cannot possibly deliver in the next six months. Why waste time even talking about them? Absolutely everything about your business could change in that amount of time. That’s the whole reason why you’ve adopted an Agile methodology in the first place, right? At most, those items should be nothing more than a vague notion listed on a rough road map (somewhere else).
- Next, get rid of all Initiative or Internal or Infrastructure tickets, period. If you wish, feel free to turn them into TODO comment(s) that are placed in an appropriate location within the source code, just in case someone happens to work on that part of the code base and should be reminded of the original notion. Otherwise, the team should focus only on one initiative (retrospective action item) at a time, and that initiative should go straight into the Open/Active column, not sitting in a wish-list somewhere.
- Third, take all (non-critical) bugs and improvement tickets that have been reported against old modules (i.e. where there hasn’t been any action and likely will not be anytime soon), and close them as “won’t fix.”
- Finally, close all tickets reported (created) by people who are no longer with the organization (no matter who’s name is currently in the “reported-by” field).
For all of the above, be sure actually delete (close) the useless ticket. Don’t just set it to some super-low priority like tabled. The ticket should completely go away — for the same reason that commented-out code should not be left lying around in your code base. Both are just noisy distractions.