Agile without a Backlog

What Is a Product Backlog?

A backlog is basically like a sorted shopping list. You need milk, vegetables, cheese, and juice, so you put those items on your list. However, you already know that the supermarket puts vegetables near the entrance, followed by milk and cheese, and juice near the checkout. So, you prioritize your shopping list to cross out items from top to bottom. Knowing what you will buy and how much it cost last time, you can also bring exact change, and you will have a perfect shopping experience. However, in the real world, you have to be very lucky for all those assumptions to be true.

Maybe one item is out of stock, and you need to select an alternative at a different cost. Maybe you have a sudden craving for some chocolate and put that into your bag without it being on your shopping list. Perhaps the supermarket is closed today, and you have to look for alternatives spontaneously.

In project management, the situation is similar. Instead of groceries, your product backlog contains tasks like setting up a website, connecting two websites, or displaying data from a database. However, in principle, the difficulty is the same. Once you start working on a product backlog item, the world might have already changed, and your original plan is no longer valid.

How Is a Product Backlog Filled?

The product backlog is about the product. Hence, we need to fill it with items relating to the product. However, what kind of product do you want to build? Maybe you think of yourself as all-knowing and creative, so you fill the backlog yourself. The challenge is not to succumb to this bias that you think you know the market. You need to interact with your customers to determine what product they want and will ultimately purchase. Items in the product backlog should be notes you took down while talking with the customer.

In our example with the supermarket, the customer might be you. While walking through the aisles, you can give immediate feedback on whether or not you want to buy the items on your shopping list. When shopping for someone else, they might be calling you if they forgot an item. Alternatively, they might even accompany you to give immediate feedback if an item is out of stock or if you put the wrong item into the shopping cart. While costly, this prevents even more costly rework later.

Getting as much real-world feedback as possible is the main difference between agile and classical product development. Without feedback from your customers, you might be developing the wrong product for months. Having your customers accompany you during the product development or at least having them test your product is essential to prevent costly rework later. The point is that while brainstorming sessions can be fruitful, it is when encountering real-world problems that you learn more about what is helpful to develop.

How Large Should a Product Backlog Be?

Think again about your shopping list. Do you put items on the list that you will buy on your shopping tour NEXT week? No, you note down items you need this week. Time spent preparing shopping lists far into the future is a waste of time. In fact, the function of a shopping list is often limited to being a reminder. We buy items as we walk along the supermarket aisles and not go down the list one by one. Maybe at the very end of our shopping trip, we double-check the list to make sure we have not forgotten a critical item. This is no different in agile product development. Sure, you might be discussing great ideas with your client about what you could do in the future. However, while discussing those items, you delay the release of the items you have already decided to release next. Focus solely on the next step and finish it as quickly as possible to produce value as soon as possible.

Let us say we could split your product into ten steps. Let us say each step takes a week to complete and that you would have a 10% overhead if you released each step separately. At first glance, the solution is clear: save the overhead, bundle the ten steps together, and release them as one big product at the end of the development cycle. However, releasing each step separately allows the customer to profit from the product while still working on the other steps. This approach ultimately outweighs the costs of the additional releases.

We can compare this idea of delayed value again with shopping. Would you prefer to starve for a month and spend the saved up money for one big haul of groceries? Or would you prefer to spend the money now and go shopping each week?

In that regard, a backlog is not a roadmap. You do not plan out what you will eat this entire year except if you know what nutrients you need each week, are on a special diet, or are sure that nothing will change. Of course, if you were to travel to Mars, you would need to do your "grocery shopping" for an entire year beforehand. However, that comes at the cost of eating whatever you take with you. You are free to sit down with your customers to philosophize what you could do for them next year and put that down as a general roadmap, but those are just that: ideas, not a fixed plan. Put into the backlog only those items you are working on right now. The length of the backlog could be seen as a measure of how long you have not talked with a customer. Vice versa, its length indicates the number of wasteful discussions you had with the customer about possible future tasks. If you see yourself just adding items that you *think* the customer needs, maybe it is better to decide to stop. Release what you have, and sit down with the customer for a new batch of items he or she needs. Suppose you have good ideas, great! Present them in your meeting. Discard the rest.

But What About Scrum?

Scrum can be agile to a certain degree if we know the reasons behind applying each part of Scrum. The challenge is that most companies implement only parts of it and are sometimes oblivious that they left out the most critical parts. Sure, there are "backlog refinement sessions," but here, the point is that they need to involve the customer. It is not a bunch of people sitting together and coming up with ideas about what a customer might want from them.

Another issue is sprints. Sprint backlogs are basically like the shopping lists mentioned above. They encapsulate a time-limited amount of work items. However, I often encounter implementations of Scrum where changes to the sprint backlog are discouraged. Why? Because the idea of Scrum is to have everything neatly organized in sprints. While breaking a sprint in the middle is possible in Scrum, this is usually a nightmare regarding re-organizing the work week and calendars. In the end, Scrum sprints are not "agile" but are merely a tool to leave developers alone for one to four weeks for them to be able to concentrate. In that regard, it is but a workaround to the problem of work items that are too large and a software architecture that is difficult to change. Better to work on your ability to create smaller work items and your architecture than on implementing a workaround that prevents interruptions. Make simplifying your architecture part of the work on every item. In our example with the shopping list, we could imagine architectural improvements as simplifying the recipes you use for cooking and having a list of substitutes in mind. This approach prevents you from having to visit several different shops.