Backlogs Are Not Waste

Backlogs Are Not Waste

To some people, to-do lists and product backlogs are waste. I disagree. I see them as repositories of ideas and options.

There is nothing wasteful about the concept of a backlog. A backlog itself is not waste. What matters is how people use them.

Wish Lists

When it comes to books, I have a wish list the size of a planet. I not only enjoy reading books; I also enjoy searching books. I check best-books list, top 100 lists, annual awards, reviews and ratings, weekly new releases, and references in books to other books. Any potentially-interesting book titles I find, go straight onto my giant wish lists.

Obviously, I won’t be able to read all those books. A wish list is a list of Could-Haves. I compare my wish lists with a landscape. I find it useful to have a vague idea of the entire landscape, when choosing my path through those mountains and forests of books. Not having an overview of the terrain would mean that each step is a blind one.

Sure, sometimes reading a random book, as an unexpected sidestep, can be enjoyable. But my time is my most precious resource. I want to spend most of it being mindful of my options.


When it comes to writing books, I am known to work with extensive checklists. A checklist is a list of Must-Haves. Every book is a different project, and therefore, every checklist is different from the previous one. But my checklists always contain items such as “Start with a story”, “Insert silly jokes”, “Add all literature references” and “Check for double spaces”.

The nature of a checklist seems like the opposite of a wish list. With a wish list, the idea is to do some of the items on the list. Even if you picked only one item from the entire list, if the item was a perfect choice, the wish list counts as a success. With a checklist, however, you must do all items. Even if you forgot only one item from the entire list, if forgetting the item causes you trouble, the checklist counts as a failure.


So what is a to-do list then? Is it a wish list or a checklist? And what about so-called product backlogs, which are basically the to-do lists for development teams? Are they mainly Could-Haves or Must-Haves?

Well, I’ve shown you before that I use Remember the Milk as my to-do list. For example, everything that I ever wanted to do in terms of marketing the #Workout book, is on a project in Remember the Milk. And I can tell you honestly, I’ve done about half of the items on that list. Has my list failed? Absolutely not. In the first six months, I sold more copies with this book than I did with the first one. In other words, all items on my to-do list were options. They were nothing more than ideas. That means, my to-do lists are wish lists.

In my opinion, with your product backlog, it should be the same. You should treat your backlog like a wish list. It is an overview of the landscape of your options. Sketching the landscape enables you to pick the most promising path for your project. And it allows you to remember what alternative paths are available to you when the current one doesn’t satisfy you.

Your supermarket shopping list counts as a checklist. Your product backlog counts as a wish list.


There is another important reason to keep lists: The science of creativity suggests that the most innovative people are those who gather ideas from many sources and turn them into repositories of inspiration. I not only have lists of books; I also have lists (or actually unsorted collections) of quotes, articles, images, half-baked business ideas, and large file hierarchies full of junk from earlier failed and unfinished projects.

Research confirms that creative people thrive in environments that are a little bit messy, where there’s just enough background noise to allow receptive brains to make serendipitous connections between unrelated ideas. The whole point of innovation is to create something new out of things that already exist. There’s not much chance of that when you don’t have any raw materials to play with.

And because our brains are not optimized for memory, it is useful to have some tools around us that allow for limitless storage of junk. Those who are familiar with Getting Things Done will recall that it is a central theme of David Allen’s productivity method: get all the clutter out of your head and into a repository, where you can browse through the ideas whenever you want.


Repeatedly, I’ve heard people say that “backlogs are waste because they are inventory”.


I disagree.

(Note: I use this picture quoting Vasco Duarte and Paul Klipp only as an example. I’ve seen the same comment many times over the last few years.)

My wish list of books is not inventory. It is an overview of options. Only the books that I actually bought, and that are still sitting in my book case unread, could be qualified as inventory, because I invested in them. (But I actually still consider them to be options, and a nice decoration of my living room.)

The same applies to your product backlog. A backlog is only “waste” when you treat it like a checklist, instead of a wish list, and then forget to process half of the items on the list. Committing to do something, and then not doing it, is potentially wasteful behavior. It wastes people’s time, energy and money. But outlining your options, and writing them down because your memory is not equipped to remember lists, is actually smart, not dumb.

Furthermore, telling developers and designers to always prune and clean up their lists of half-baked ideas is like imposing a clean-desk policy on creative workers. It reflects a mechanical view of productivity, and it might be the silliest thing you could ask from people who are expected to be innovative. If they are not allowed to keep lists of ideas, how will you expect them to create innovative products?

Treat your backlog as a messy repository of half-baked ideas, instead of a sanitized production queue.

There is nothing wasteful about the concept of a backlog. A backlog itself is not waste. What matters is how people use them. Creative workers need tools to store their ideas and to remember their options. Only factory workers should be expected to keep their inventory low and their machines clean.

Telling people that backlogs are waste is not helping anyone to be more innovative.

photo credit: (c) 2013 Barnyz, Creative Commons 2.0

  • The Newest Management 3.0 Game: Improv Cards
  • Champfrogs: A SketchKeynote Presentation
Related Posts
free book
“How to Change the World”
  • J. B. Rainsberger

    I agree: the backlog itself can’t be a problem, unless its very presence stops us from doing something else.

    I haven’t opened OmniFocus in a few years. I still have dozens of projects in there. Right now, it only costs me a bit of disk space, so it doesn’t have to provide me much value to justify the price I’m paying to keep it around.

    If I performed the GTD Weekly Review on that repository of ideas every week, though, I’d have got rid of 90% of it by now, or at least downgraded 90% of the projects to “review once per year”. (I like that OmniFocus has that feature.) Reviewing weekly projects that I have no chance of starting seems wasteful to me.

    Even so, I think about our friends the story cards. I remember people asking, “What if we lose the cards?! That’s why it has to be a spreadsheet!” I remember answering, “If it’s important, we’ll remember it and can rewrite the cards. Often when we rewrite the cards, the new draft is better, anyway.” This is the sense in which one might say that “the backlog is waste”. Even so, I prefer to say, “The backlog is only a draft of what we might do.” This sounds pretty compatible to your opinion on the matter.

    • jurgenappelo

      Agreed. Except for “If it’s important, we’ll remember it.”
      I’ve been known to forget some important things in the past. 🙂

  • Pingback: Backlogs Are Not Waste - NOOP.NL | CXO.Care | ...

  • pklipp

    You just said the same things I’ve been saying for years and reached the same conclusion that I reached while fervently asserting that I am wrong. I once called backlogs waste (in a longer Tweet than the one stripped of context by Vasco) to encourage people to think carefully about the value of time invested in them because I have seen teams and product owners spending ridiculous amounts of time estimating, re-estimating, prioritizing, and re-prioritizing lists of features, half of which never, ever, get built.

    Backlogs do represent investment because all we invest in software development, after all, is time. A backlog is waste in the same way that a half-finished feature is waste (as described by Mary and Tom so many years ago that I’d expect everyone in the industry to have been exposed to the idea by now). Something good might come of it, but at the moment it’s just psychic overhead that isn’t generating revenue or making anyone happy yet.

    For that reason, I prefer to have a product roadmap, which differs from product backlogs I’ve seen (and I’ve seen hundreds) in that it’s built around goals and a vision and pushes high-granularity solution design to the last responsible moment.

    Kanbanery’s roadmap has a very broad long-term goal (The easiest visual management tool to learn and use without sacrificing powerful change-driving feedback), a list of half a dozen major goals for the year, a list of areas to focus on this quarter, and a list of features to add this month.

    We have a backlog, dating back over ten years, but it’s so full of duplication, irrelevant ideas, customer requests that deviate from the product vision, bugs that have been fixed ages ago or were found in code that we’ve since thrown away and suggestions that have been rejected that I never look at it, just as J. B. never looks at his. Many hours have been spent on that list that I never look at, and the closest I can come to minimizing the loss is to write that time off as a sunk cost and learn from it.

  • Mike Leber

    Your post basically makes clear, that we want to deal with things, a backlog isn’t. Basically as per the word’s definition, a backlog is more or less a container of planned, if not to say committed work. And that’s where the comments about backlogs in terms of waste stem from. Because from this perspective we grow queues, which have negative economic impact, especially when working in a dynamic environment.

    Hence it makes sense to make the clear distinction (like you do in your post) and rather talk about options, ideas etc, instead of backlogs. Commitment is then also optional and it will be deferred to the latest possible moment.

    The problem is digital information – as Don Reinertsen references HP in one of his books: “Our inventory is bits on a disk drive, and we have very big disk drives here at HP!”. The cloud, Evernote (just consider the product name …), etc. are the modern equivalents here.

  • Pingback: Five Blogs – 15 May 2015 | 5blogs

  • Pingback: Backlogs Are Not Waste – NOOP.NL | Development Block

  • Pingback: From my reading list #26 – May 25th, 2015 | Pascal Laurin

  • Pingback: Reading Recommendations # 18 | Adventures in QA

How to Change the World - free Workout - free