Product Backlogs Are Not Backlogs
A product backlog isn’t a backlog; it’s a wish list with deadlines you may never keep.
I cancelled a project today and deleted the entire backlog.
No, scratch that.
I deleted the entire wish list. I had no backlog, only a list of options.
The wait is over - the Sintra AI Helper Builder is officially live. As of today, you can stop trading your time for every single task and start delegating to agents built on your own logic.
Whether you need a specialized researcher or a digital assistant that handles client FAQs exactly how you would, you can now build it in minutes. Don’t just use AI - create a version of it that works specifically for you.
When I ask Claude for the definition of “backlog” in one small paragraph, it says,
“A backlog is a prioritized list of work yet to be done — features, tasks, fixes, or requirements — that a team draws from to decide what to tackle next. In agile contexts, it’s the single, ordered source of truth for everything the team might build, with the most valuable or urgent items floating to the top and the vaguer “someday maybe” stuff sinking to the bottom.”
It’s practically the same as the definition that ChatGPT gave me a while ago:
“In project management, particularly Agile methodologies, a backlog is a prioritized list of tasks, features, user stories, and other items that need to be completed. It serves as a dynamic to-do list for a project, capturing and organizing the work identified for the project but not yet accomplished.”
The official dictionaries say,
“Backlog - an accumulation of tasks unperformed or materials not processed” (Merriam Webster)
“Backlog - a large number of things that you should have done before and must do now” (Cambridge)
“Backlog - an accumulation or buildup, especially of unfilled orders, unconsumed products, or unfinished work.” (Wiktionary)
Each definition shows that a backlog is a list of work that you must do. You must fulfill all customer orders for a web shop. You must complete all tasks of a visa or immigration process. You must clean out the garbage bags you’ve accumulated under the stairs. And yes, if you use Scrum, you commit to finishing all tasks on your Sprint Backlog. These are all true backlogs: collections of things you still need to do.
None of this applies to product backlogs.
Technically, a product backlog mostly consists of ideas. Only the top part can be called a backlog. Only the part where you’ve committed yourself to completing the items should be called a backlog.
My long list of places still to see before I die is a bucket list, not a backlog.
The interesting films and TV shows I collect on IMDb are a watchlist, not a backlog.
The many rows of unread books on my bookcase are my tsundoku list, not a backlog.
The ideas I have for our new kitchen (before I see the vendor’s cost estimate) are an options list, not a backlog.
In fact, all the upgrades and repairs I keep track of for our house (because entropy is a bitch) is a wish list, not a backlog.
Most of what people call a product backlog is actually not a backlog: it’s just a collection of ideas and options for features, objectives, stories, etc. You’re not really responsible for completing them all and ticking them off your list until the list is empty. Because watchlists, wish lists, bucket lists, and option lists are never empty. They always refill with new ideas faster than you can clear them out.
When you’re able to politely or hesitantly say, “No, we’re not going to do this,” to many of the items on your list, you don’t have a list of “tasks unperformed.” You don’t have a list of “things that you should have done before.” You don’t have “a collection of unfinished work.” You don’t have a product backlog.
Call me conservative. Call me a linguistic prude. But referring to a list of features as a “product backlog” was a very bad idea from the start. (And which language-agnostic idiot did that, anyway?) It gives other people (usually your customers) the impression that you’re still going to do all of that. Because you call it a backlog, it means you’re going to clear it all, right? That’s what real backlogs are for! But you and I know that you’re never going to see the end of that “backlog.”
You may be interested to read what Claude added as a remark:
The word “backlog” carries a promise. Whether it’s a stack of webshop orders, a queue of visa applications, or the unplayed games you bought that are guilt-tripping you from the shelf, the meaning is the same: things placed here are expected to be cleared. Put something on a backlog, and the implicit contract is that someone, eventually, gets to it.
The etymology backs this up. From the 1930s “arrears of unfilled orders” to the older “pile of work to get through,” every list-shaped sense of the word promised clearance. The one pre-Scrum sense that didn’t — “something held in reserve” — wasn’t a list of discrete items at all. It was fungible bulk: fuel, cash, stock you draw from without committing to spend every unit.
Scrum welded these together. The product backlog has the itemized, prioritized structure of the arrears queue, but the no-clearance-commitment of the reserve. A list of distinct candidates, most never expected to ship, many explicitly meant to be deleted. That hybrid interpretation is new.
So the honest charge isn’t misuse. It’s that Scrum borrowed a word meaning “things that will get done” to name a thing that means “things we might do.” A product backlog isn’t a backlog. It’s a bucket list.
Claude already seems smarter than most product people. 😉
Jurgen, Solo Chief.
P.S. This post was adapted from an earlier version on the unFIX blog.
The wait is over - the Sintra AI Helper Builder is officially live. As of today, you can stop trading your time for every single task and start delegating to agents built on your own logic.
The 5 Steps to Lean AI: Kill First, Automate Last
The trouble with automating too early is that you scale the mess.
This has been annoying me for years as well. A backlog is a list of things that should have been done by now but have not. A plan or roadmap is a statement of what should be done in the future. I never understood how this term became currency when there were plenty of better, existing ones.
The argument seems to hinge on the idea of backlogs being work that must be done, but that seems weak.
First, not all of the definitions explicitly include the concept of "must". Of the 5 definitions, only ChatGPT's ("need to be") and Cambridge's ("must do now") include the idea of "need" or "must". The argument that a backlog is work that must be done doesn't seem to hold up when 3/5 of the definitions don't support it.
I also think the idea of "need" or "must" is different in an agile context. A hallmark of agility is responding to a changing environment. At a given point in time, the backlog represents the set of work that people believe "needs to be" done or "must be" completed. However, by doing the work and collaborating with stakeholders, we'll find things that must be done that we didn't think of or learn that something we felt was needed isn't. Just because we believe something must be done today doesn't mean we'll continue to hold that belief tomorrow once we see something that changes our minds.
If something won't be done or doesn't represent something someone thinks is necessary, there's no reason to put it on the backlog. Work that is far beyond the current vision for the product, for example, doesn't need to appear as an idea or option.