Our problem with backlogs – DEV Community

Over a year ago, we launched our dev tooling startup. One of the biggest pitfalls for new companies is focusing on the wrong priorities – over-engineering your scaling capabilities too early or neglecting customer value.

From the outset, we decided to create a culture where everyone truly owns their work. This approach not only ensures we’re focusing on the right things. I have always enjoyed working most on the things I find important.

One of our early discussions was about adopting a ‘no backlog’ approach. Now, with a team of 8 engineers and over a year of experience, we revisited this decision to see if it still made sense.

It was a fun exercise. We got our backlog frustrations from previous workplaces out of the system, and discussed the advantages and disadvantages we have identified in the past year. I’ve summarized it here.

If you consider deleting your whole backlog or moving to a less backlog-centric approach of software development, I hope to give you some good insights.

What exactly is a backlog?

To start the discussion in the now larger team, I wanted to get a feeling for the backlog vibe. When I asked around, I got answers like:

• An ordered list of tasks that we need to complete
• A way to structure work
• A way to remember past discussions and conversations

But also:

• A dumping ground for unimportant tasks
• A place I can put stuff in. I know we’ll never work on that. It gives me a good feeling of putting it there.
• A to-do list that never gets done
• A good tool to shut down discussions

For me personally, a backlog is a collection of tasks that aren’t important enough to do right now. If they were, we wouldn’t be stashing them away. After years in software development I’ve come to see backlogs as more of a hindrance than a help.

When I refer to ‘backlog’ I do NOT mean a list of tasks that you need to do in the next short iteration (1-2 weeks), but anything longer than that (as in ‘product backlog’).

So, let’s dive into some of the problems I see with backlogs.

1. They are designed to be a dishonest conversation

Backlogs often lead to some pretty dishonest conversations. Picture this: A stakeholder urgently requests a new feature, as is often the case. The product owner, instead of outright saying, ‘This isn’t a priority right now,’ adds it to the backlog. The stakeholder walks away thinking their request will be addressed in x days, while the product owner knows it probably won’t be touched.

It’s an easier conversation to have than just saying we will never get to it because it’s not important. This is what’s happening every time you add something to a really long product backlog. This cycle keeps everyone happy on the surface but doesn’t solve the real issue.

‍

2. The never ending list

Backlogs have a large gap between expectation and reality even for the most experienced of teams. We all would like to see a nice, steady burn-down of tasks. In reality, backlogs rarely shrink. If it’s still growing after the 12th iteration, that just breeds frustration for everyone involved.

An empty backlog is a myth. We’ve never seen such a thing in any of the companies that anyone in our team has ever worked in. Unless we decided to delete the old and start with a new one out of sheer frustration.

source: https://www.allankelly.net/static/presentations/Shrunk.pdf

3. They are a COLOSSAL waste of time

Maintaining a backlog eats up a lot of time. Teams spend countless hours refining, grooming, and updating tasks, creating wireframes, and ensuring every detail is documented. Yet, by the time a task actually is being worked on, the original requirements or context may have changed substantially, making all that prep work useless.

Every moment spent on a task that isn’t immediately being picked up is time wasted. The gap between defining and implementing tasks often means the work becomes obsolete as requirements and reality change, as they always do in software.

source: https://lucasfcosta.com/2023/02/07/backlogs-are-useless.html

4. They shift bottlenecks (and blame) between different roles

Imagine a customer success manager who asks for a specific feature for a specific customer. The dev team has an open backlog policy, everyone is allowed to add a ticket. The engineering team has to take a look at the item, refine it, then potentially estimate the effort (#noEstimates, but we are trying to focus here). The refined task never makes it to an iteration. Different prios.

The blame for not completing the task on time lies with the engineering team. If they ONLY had worked faster.

source: https://lucasfcosta.com/2023/02/07/backlogs-are-useless.html

So you add a product owner to the front of the process. We don’t believe the role must be tied to a specific person, but the concept is solid. The prioritization is now done with the team at a much higher level of abstraction BEFORE stuff ends up in the backlog.

Ideally, you’ve matched the input rate and the output rate. Now, It’s much faster and cheaper to throw stuff away.

source: https://lucasfcosta.com/2023/02/07/backlogs-are-useless.html

Part of our problem with dedicated product owners is that they take away too much ownership from the team. They often just take blame from both stakeholders AND dev teams, and can quickly become a single point of failure for the product’s success.

• Are they good at prioritizing and keeping stakeholders at bay?
• Do they have enough authority to make decisions?
• Are they blocking development by being too protective of the backlog?

Something that came up in the discussion summarized it perfectly:

“We used to have some fierce guardians of the backlog at my previous company. It was impossible to get anything in. Didn’t go well for either the product or the company.”

5. Backlog bias when discussing importance

Backlogs also introduce significant biases. Tasks added to the backlog represent decisions made without the necessary input from the current context. As time goes on and things change, these tasks might no longer be the best solution. Yet, teams continue with them simply because they’re in the backlog.

I’ve seen this happen over and over: a task sits in the backlog for months, gets discussed in every iteration as critical, only to become irrelevant when it’s finally addressed.

So, what did we do instead?

This quote of Allen Holub is about more than backlog size. It gives us a way forward without one.

source: https://x.com/allenholub

In product development, detailed long-term planning should be limited to high-level priorities — knowing what to build and why. The next steps become clear through building and immediate feedback. A backlog often gets too granular for planning beyond the next 1-2 weeks.

When you ask developers about the most important task, they’re usually already aligned. While there may be minor differences in preferences, identifying the top priority right now isn’t typically an issue.

1. Continuous Discovery

We adopted ‘Continuous Discovery’ practices, focusing on ongoing conversations with customers and stakeholders to gather insights and feedback. It’s about always reassessing priorities based on the latest information, ensuring that we are working on what matters most.

Rather than relying on a static backlog, our process is fluid, with priorities shifting as new information emerges.

However, we’re not starting from scratch each week; the Opportunity system within Continuous Discovery helps us stay on course. Opportunities highlight customer needs and pain points without jumping prematurely into solutions on a low abstraction level until absolutely necessary. They ensure we tackle the most critical issues first.

For a deeper dive, check out Teresa Torres’ explanation in Product Talk.

2. Aligning with goals

A key strategy is to focus on overarching business goals instead of specific tasks. This ensures our efforts align with the bigger picture and adapt to current priorities. This goal-oriented approach helps us identify critical problems without getting stuck on a fixed list.

This is, of course, the bread and butter of engineering and product leadership in all companies. It’s also really hard. We often struggle with making our goals measurable for small increments for example.

3. The case for not listing ideas

“But what about all my good ideas that I will lose if I don’t write them into a backlog?”

First, I really think that if the idea is good enough it will come up again, because you will spend more time thinking about the problem space. You might come up with an even better solution.

You should always rethink your ideas. You should be able to kill your darlings, if they don’t serve the purpose anymore.

More than a year into Octomind, we know what ideas were discussed and discarded, and why. We have the advantage of being a small team, so onboarding new colleagues to our mental model is still easy. I don’t think a backlog of outdated items helps the newbies anyways.

4. Cheating with mini-backlogs

We collect bug tickets, sort critical ones in real-time and run a bug triage every week to address the rest. We have a zero-bug-policy, which means they are just as important as any of the tasks that we planned for that iteration, and this ensures the bug backlog doesn’t grow indefinitely. Most of us get anxious if there’s more than one page of open GitHub issues. It seems to be working for us.

Is it cheating? You decide.

This might not work for you

Our business model relies on other vendors’ LLMs, a landscape that shifts constantly. We must adapt quickly to avoid investing in solutions that could be outdated with the next GPT release.

I’m very well aware that not all software development is the same. Some ecosystems require long-term planning, extended development cycles, and careful rollout, especially in industries with strict regulations or safety-critical applications (looking at you CrowdStrike). Large engineering teams need robust processes so the house doesn’t fall apart.

We might eventually outgrow this set-up and introduce more backlog-like processes. Until then, we’ll do our best to keep the backlog monster locked away.