Let’s Stop Creating Silos With Multiple Backlogs. There’s Only One!
One product, one Product Backlog. Multiple Product Backlogs split teams and reduce collaboration. It’s time to change it.
One product, one Product Backlog. Multiple backlogs split teams and reduce collaboration. It’s time to change it.

“We have to look at our Tech Backlog before we discuss the Product Roadmap.” said the CTO, and I immediately felt confused and annoyed.
I wondered why do we have multiple backlogs for the same product. I was new at the company, but I was sure multiple backlogs for a single product would lead to silos and inefficiency. Not surprisingly, we constantly faced communication problems and generated false expectations.
The Scrum Teams were frustrated. Product Owners and Developers couldn’t deal with the situation. No one had the whole picture. The Tech Leads managed the Tech Backlog while the Product Owners managed the Product Backlog. Planning the Roadmap and Sprints was a synonym of war due to a lack of shared understanding.
We wanted to do Scrum, but our misconceptions locked us in silos. We prioritized processes over collaboration. Inevitably our results were watered down.
Individuals and interactions over processes and tools
— Agile Manifesto
There’s only one Product Backlog
Why do we love to complicate things? Why do we want to overcome challenges with new processes? Until we have a real agile mindset, we cannot benefit from an agile framework.
“A clever person solves a problem. A wise person avoids it.”
― Albert Einstein
Doing Scrum with one team might be simple, but once we start scaling with multiple teams, we face new challenges. That’s why we may find a way out by introducing new processes. Bit by bit, we transform our Scrum into a heavy machine, ultimately leading us to inefficiency.
A common misconception is creating multiple backlogs for the same product even though Scrum is pretty clear. One product, one backlog.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
Scrum is supposed to be simple. That’s why, when we need to scale, we should keep it simple as well. Once we create more processes, we inevitably reduce collaboration. People tend to become less creative and more process-oriented. To thrive, teams need to have an environment that prioritizes collaboration over processes.
Multiple Backlogs lead to numerous problems
If you want to work with multiple backlogs for the same product, you better know what waits for you:
Confusion. Silos. Frustration.
I’ve been in some situations where we had multiple backlogs for a single product. Even in different companies with different variants, the result was the same: Teams got locked into silos that held them from succeeding.
The idea behind splitting the Product Backlogs into different boundaries (tech, discovery, and so on) is that teams can organize the work easier. For example, technical requirements could be managed fully by the Development Team, or the Discovery Team manages discovery backlog. But the consequences of this set-up are:
Misunderstanding: teams for the same product may work towards different directions. They don’t know what the other teams are working on or planning to do.
Silos: every team has a specific responsibility. They collaborate less and focus more on their part. The agile mindset disappears.
Frustration: developers feel like assembly line workers. They execute what the discovery team defines as important, but they are not part of the whole. They are mere executors.
Confusion: the Product Owner struggles to understand what is going on because she might not have an eye on each backlog. Multiple backlogs put teams in multiple directions. Dependency among teams increases, while efficiency decrease. The Product Owner focuses on the process instead of maximizing the value.
In my opinion, multiple backlogs for the same product should not be an option. If we want to foster collaboration, we have to avoid splitting the Product Backlog into different boundaries.
How can we stick to a single Product Backlog?
We should keep an agile mindset. Once we decide to scale Scrum, we should be aware that we also scale the dysfunctions. They should be fixed before scaling. That’s why we should avoid creating new processes; they won’t solve the root cause.
One Product Backlog ensures simplicity.
Everyone works in the same direction.
Team members keep the big picture in their minds.
Collaboration is natural. Silos have no place.
Dependencies are reduced due to the stronger collaboration between the teams.
No overhead to manage multiple backlogs.

During my journey, I’ve observed a common pitfall. Many companies start scaling before they master Scrum with a single team. Therefore, they face many problems while adding more teams. Before we think about scaling with Scrum, we should be able to do Scrum properly. That will save us from endless drawbacks.
If we do Scrum, we can scale with Scrum. Real Scrum teams are:
Cross-functional: the team has all skills needed to build meaningful and delightful products.
Self-organized: the team defines how they work. Nobody needs to manage them. The team is responsible for themselves.
Autonomous: the team is empowered to make any decisions as needed. They don’t need to ask for approval.
Goal-oriented: Sprint by Sprint, the Scrum Team focuses on achieving the Sprint Goal instead of delivering tasks. The Sprint Backlog is not a prison. The team has the space to do whatever they want to achieve the goal.
Empirical: the team accepts they don’t have all the answers up front. They build and learn. They take feedback seriously. The Scrum team becomes a better version of itself Sprint by Sprint.
It may seem obvious what I’ve just written, yet it’s not reflected in many teams. Many teams think they do Scrum, but they are:
Incomplete: not all skills are present at the team. For example, the designer is part of another team and has a different set of priorities.
Features-driven: the goal is to deliver features. At the end of the Sprint, what matters is shipping new features. More is synonymous with better. The Sprint Goal is ignored.
Overconfident: the team perceives the validating hypothesis as a luxury waste of time. They know exactly what to build. Therefore, the focus is on building instead of an understanding of what to build.
Please keep it simple, focus on collaboration instead of processes.
I started working with Scrum in 2012. I’ve been part of many different situations. Whenever we tried to overcome a challenge by implementing a process, we introduced more obstacles to our scenario. But when we decided to step back and evaluate the situation in-depth, we found opportunities to simplify, which led us to better results.
Scrum is not meant to be a silver bullet process. On the contrary, Scrum is a process framework. We can add more components to Scrum, if needed. But before we do that, we should ensure we don’t transform our Scrum into a watered-down version. We can’t expect an astonishing outcome from a sub-optimal Scrum version.
For most of the problems I faced with Scrum Teams, the solution was found by asking what we are doing wrong with Scrum? Scrum was rarely the problem, but our process-oriented mindset created many problems.
“We cannot solve our problems with the same thinking we used when we created them.” — Albert Einstein
Do you want to write for Serious Scrum or seriously discuss Scrum?