I don't know what I would do without some sort of work list. If I couldn't jot down the occasional "I need to do X" thought for later, I'm pretty sure I wouldn't get any work done! So whether you call it a todo-list, backlog, roadmap, queue, inbox, or rug (for sweeping things under), I need one.
Backlogs address a real need but also create a new issue: They grow. This might not seem a particularly big problem. Sure, it doesn't feel great to have this list of a hundred things we want to do that doubles in size every year, but does it really hurt anyone? Yes it does, says Donald G. Reinertsen in his amazing book Principles of Product Development Flow. He introduces yet another term for backlog, product development inventory, and claims its cost is massively underestimated.
Reinertsen identifies the following costs of product development inventory:
Longer cycle time. Cycle time is the time between a task's conception and completion. That includes the time we spend working on a task but also the time it sits in a backlog waiting. The longer the backlog, the longer the wait.
Increased risk. This follows from the previous point. Consider as an example the task to fix a bug in a piece of software. Waiting with a fix increases the damage the bug can do, gives the buggy code time to integrate with other code making it harder to change and fix, and gives time for context about the buggy code to seep away, increasing the cost of a fix.
More variability. When temporarily blocked from moving forward with one task a large backlog will always provide another one to work on instead. This creates a bias to having lots of things going on at the same time, which makes it hard to bring focus to those few tasks which are a bit harder than the rest. Such tasks can drag on and result in sudden unexpected delays.
More overhead. Backlogs require prioritizing. Prioritizing tasks requires (re)gaining context on what these tasks are about. If someone else requested work they'll appreciate the occasional status update about how that work is going. The larger the backlog, the more of this type of work we have to do.
Lower quality. If a single step to improve a product takes more time (longer cycle time), then our feedback cycle will be longer too. Reducing the quality of feedback will hurt quality itself.
Less motivation. This one is most intuitive to me. Seeing my todo-list shrink makes me feel good about myself. Seeing it grow not so much.
The upshot of all this: prefer shorter backlogs. Anyone in the market for a 'short backlog methodology' has their pick of gurus. Reinertsen presents a number techniques in The Principles of Product Development Flow. But if you haven't chosen an approach yet, or if the approach you did pick isn't working for you, here's a backup option I quite like: throwing stuff away. Deleting tickets can be scary, but I find a long backlog scarier.
Top comments (1)
One approach I've found very helpful: organize my TODO list, or backlog if you will, by the day or time in which I intend to do the work. This forces me to acknowledge "hey, I'm not going to have time to do this!" more often, which results in a more realistic list. Sort of a half-measure compared to what you're suggesting, but I've found it helps. I do wonder what that would look like in a team context, though.