Why “Just put it in the backlog” is a terrible idea

You know that (in) famous sentence: “just put it in the backlog”?

It started with well intentioned Product Owners in Scrum receiving requests from everywhere in the organization. They were trying to listen to everybody but not rush into decisions. It was an experiment, and a valid one. Then eventually it became so normalized as a practice that I even hear it being taught into some agile classes as if more than inoffensive it was positive.

I’d say it got so much traction in the world of misunderstood Agile, in particular Scrum in bigger organizations. It is definitely something I have experienced countless times and I’ve seen so many product people proudly using that sentence, feeling great that they dodged one less problem.

Except that they didn’t.

In this post I will explain why “just put it in the backlog” is a terrible idea. And what to do instead.

What is a product backlog?

Let me start by explaining what a backlog is.

A product backlog is a tool for negotiation, communication, and decision-making regarding the product in question. It can live in Jira, in Trello, in paper. It can be represented in whichever way you want. It just has to be visible and presented in a manner that stakeholders (other people, other teams) can understand and ask questions about it.

In a product backlog you have an ordered, prioritized list of items to be done. It’s up to you if you add bugs, features. Whatever you call them is also fine, so long as you understand that those are product items yet to be developed. Items on the top of the backlog are of the highest priority. Hopefully priority and value align, so you do first what matters most. But we’ll talk about that some other time.

The problems with “just putting it in the backlog”

There are many problems. I will tell you of just a few, dividing them into 3 lose categories.

1 – structure issues

I’m sure you started spotting the first problem. “Just adding” stuff to the backlog disrespects the definition of a backlog. It becomes a pile of ideas, of which we are not so sure about the merit. There is not proper organization, order.

And it grows. So much so that it can become unmanageable. A wish list of useless items never to be developed in your product. If you don’t believe me, you should see what my Amazon Wishlist and Amazon save-for-later look like. And it’s not only mine. It’s a natural effect of the ability of having space. Hoarding. If you let it, the backlog always grow.

Bu the intention of the backlog is to point to progress and be finished. It never really will be all done (unless your product phases out), but it’s a productive conflict of forces.

2 – process issues

Because the backlog is now growing big, you just gave yourself the need for backlog refinement. That’s right, unpopular opinion for you there, but let it sink for a minute. The reason for most backlog refinement is because work items, product items, user stories, whatever have you, gets added to your backlog as… one-liners; short sentences; ideas.

You just created the need to discuss the work items in depth, sometimes much later after their being added to the backlog. At this point, as you uncover pieces of the backlog item… is it still in the same priority? And now it might have become much bigger than the original idea. What to do other than whiteboard and discuss with a ton of folks to figure out what’s essential?

Obsolescence is big in big backlogs. You can’t give them all your attention and you probably have no clue at some point what “Move files from one folder to the next” means anymore, number 113 on the list. This is actually a true (horror) story in my life, by the way, as I was just starting out in 2012. It stuck with me. Trauma.

I’m sure you are seeing the time wasted in trying to retrace and recover meaning and importance for those backlog items. The engorgement of your backlog management process. And the need for more robust tools to host such a huge messy list.

The irony is that the backlog IS the tool. It was a tool that should make things easier, visible, communicable. But it’s now endangered by blobs of meaningless data. The tool needs a tool to be managed.

3 – stakeholder issues

I think the worst part though is the conversational void with the “just put in the backlog”. You see, the backlog is a tool for communication. So, communicate. Why do you need this item? Why now?

The backlog is a tool for priorities. I cannot give this news shiny idea a proper place in the backlog when it’s value and meaning are not clear.

The backlog is a tool for decision-making. So make a decision to not put anything in there that you don’t know, don’t want or don’t understand.

Not dealing with the conversation when the request is made only postpones it. It still needs to be had, only later with more anxiety. Because if you did not notice it, most people assume that when you put stuff in the backlog that means you will give them some kind of priority or attention. They don’t realize you just dodged them. And they would not be so happy if they knew!

Ultimately the rush to put stuff in the backlog but not to look, discuss and validate their importance and merit reveals deeper issues in the organization:

• It shows that people are overly busy and have no time to discuss anything.

• It reveals the multitasking bug.

• It shows that there are 5 priorities number one; 10 priorities number 2.

• You are starting more stuff than you finish.

• Maybe even a generalized lack of understanding of value.

• Inability to timely experiment. Inability to make decisions.

I could go on and on, but I will finish here with a real example: I once worked with a team that for a whole year never finished anything. NEVER FINISHED ANYTHING. The product team was constantly asking for modifications and new items before anything hit production. You surely can guess the morale of that team.

What to do instead

The backlog isn’t immutable, much to the contrary. But a bit of an orderly fashion to keep it tidy is advised. I’ll give you 3 experiments to try and see what happens. I’d love if you report back from the trenches on a comment!

Experiment #1

My most important suggestion is that if stuff comes in, a decision should be made. Items should not “enter the backlog” by accident or happenstance. The backlog as a decision-making, communication and negotiation tool is at full force when you do this.

THAT’S HOW you keep at bay those stakeholders who keep asking for new stuff without much thought, not by buying time with “just put it in the backlog”. You educate them on value, on priorities, just by reminding them the negotiation that needs to be had. There is only room for so much work to be done and work is done sequentially.

Experiment #2

Make every request to put items in the backlog become an “inquiry” or “ideation” meeting or session.

It’s similar to the previous one, but not the same. Pay attention to the nuance. In experiment #1 you test people’s ability to decide and prioritize. In this one you test their ability to defend their idea and ascertain value.

To begin with, people will only take up on your offer if they have more than a nice-to-have idea. They have to be willing to fight for that feature or request. They will find time to discuss with you in front of a board, look at numbers. It’s a commitment to the process, knowing that even though they can meet with you, their request might still not get accepted. So, people only do this when they are really invested. And you gain valuable time because that meeting is your backlog refinement and prioritization session altogether. And you are not wasting your time cleaning up old requests that no one even remembers who asked for.

This experiment tests value as well, because sometimes we are passionate about things… that cannot stand on their own. As we discuss ideas, we see more and more holes in it and then it’s either back to the drawing board or abandon it for now. It’s still a great investment of time, because recognizing paths you don’t want to take with your products and services is at the hear of what product owners and managers do.

Experiment #3

You can still have a wish list. That’s right! Your product, your rules!

If you do decide to keep a wish list, make boundaries very clear. Keep it separate from your product backlog. Ideas and suggestions are valid, but they are not actively managed by you. You can keep a log somewhere else, ideally visible and public as well, where people drop in their ideas. You can even enable community aspects and see what gets voted on more often. The open source community does that!

Then, every once in a while, when you have time, you check upon it and make decisions. Is there anything worth discussing and bringing to the backlog?

It is very important that you set the expectations with all your stakeholders that the wish list is not the backlog and that you make no commitments of even regularly looking at those items, so people know that the list is unmanned.

Over to you

Backlog management while simple is not trivial. But healthy backlogs are the gateway to great products and to the sanity of the product owner/manager and the teams developing products!

I hope this post gave you an idea on how to argue your way out of the madness of stuffing your product backlog management with useless items that you have to clean or purge regularly.

Which problems do you recognize in your own reality from “just putting it in the backlog”? which of the experiments are you more compelled to try? What else would you suggest?

If you are an agile coach or a scrum master, hop on this other blog post to know more ways of in which you can help a product owner.