No backlog

At some point, you’ve probably asked yourself: “How do we manage our huge backlog?”. The truth is, a massive backlog is a problem in itself.

Hello, developers! 🚀

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!

Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!

As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇

Now, let's dive into today's micro-topic!

In short

📌 Traditional backlogs often become overwhelming lists of outdated tasks, making prioritization difficult and slowing down development.

💡Instead of maintaining an ever-growing backlog, teams should focus on immediate, high-value work.

⚡ Rather than hoarding ideas in a massive backlog, teams can separate strategic planning from tactical execution.

🔄 By enforcing a Work In Progress (WIP) limit, teams ensure real-time decision-making fosters ongoing discussions, ensuring alignment with business priorities and reducing wasted effort.

🚀 No Backlog

Inspiration for this issue comes from this Linkedin post from Allen Hollub.

At some point, you’ve probably asked yourself: “How do we manage our huge backlog?”. Some other times, you probably notice that, even if you already have a long list of things to do in the backlog, there is always something new popping out that is more valuable and has higher priority than older items.

The truth is, a massive backlog is a problem in itself. If your team has more work queued than they could realistically complete in months—or even years—it means you're hoarding ideas instead of delivering value. A big backlog is also a symptom of big design upfront: you try to decide today what to do in 6 months, and most of times you even describe it in details in written format, hoping that reading back to those details will help you start faster in the future - then, most of those items are never worked, wasting away the time to write those details, and even when they are worked, those details are unclear and outdated.

The hard truth? Just throw it all away. Yes, everything.

Afraid of losing important ideas? The most important work will resurface naturally, because the real priorities never disappear.

A Backlog is Not a Wishlist

A backlog should not be a dumping ground for every idea that comes up in a meeting. In Agile, we prioritize what needs to be done now—not someday, maybe, eventually. A bloated backlog only causes delays, distractions, and unnecessary debates.

Instead, apply a Work In Progress (WIP) limit to your backlog, just as you would in a Kanban system. Only allow a set number of items—let’s say a month’s worth of work, at most. If a new priority emerges, something else must go. This forces real prioritization and avoids the backlog graveyard effect.

I can hear your question now: “Where do I track my roadmap?”, or “Where do I put all the ideas?”. The first thought about this should be: “Do you really need to track the ideas, or the roadmap?”. You probably answered “Yes, of course!” - I understand that, but sometimes it might not even be necessary. Some other times, you might just use something simpler. If you really want to structure your work starting from ideas, and to represent them in your own tool, I would suggest you to use different tools so that you are not forced to turn everything into a backlog item.

What we are doing in Muffin, for example, is to take advantage of the different tools that Jira provides:

• Atlas for the roadmap: we make a draft of the roadmap on Miro, just for simplicity, and then we move it to Atlas to take advantage of his followers/notifications functionality, that help us to keep everyone updated on any news about the forecast with ease;

• Jira Product Discovery for ideas triage, and as connection point for the forecast plan of the roadmap and the real work we are currently doing: while the roadmap on Miro/Atlas is represented in quarters to enable a better view of the consequentiality of things in the forecast, here on JPD we represent it in NOW, NEXT, LATER - which is a way for us to zoom on what we are doing in the current quarter (NOW) while keeping an eye on the next quarter (NEXT), and leaving the rest for the future (LATER);

• A basic Kanban board with the TODO/INPROGRESS/DONE structure, to represent the work in process (WIP); the WIP for us is basically a zoom on the NOW, where we only represent the items IN PROGRESS (or just about to be started) from the current quarter; the backlog will be contain the next prioritized bunch of things to work on from the NOW column.

This way, we aim to decouple the strategic plan from the tactical one:

• the strategic plan is the forecast and plan of the year, which is high-level and is longer-term, therefore it is very likely to be changed and updated based on new learnings and things happening ➡️ Atlas / JPD

• the tactical plan is the actual work we plan to do when we attack a piece of work from the NOW column, usually about the next 1-3 week, therefore we can expect more precision here, and less possibility for big changes ➡️ Kanban board

As you may have understood, our real backlog it’s just the tactical plan: no more than a month in advance is put in the backlog, with just enough details to start the work.

But, be careful!

We are aware, and I want you to be aware too, that there is a risk of building a “backlog of backlog” with this approach. We know it, and we want to avoid that.

How do we try to avoid it? I believe in the following quote:

plans are useless, but planning is fundamental

We build the forecast, and draw it as a roadmap, not just to merely agree on a high-level plan: we mostly do it for the process! All the conversations happening around the plan, and then all the weekly conversations to discuss it over time and eventually adapt it to learnings and happenings - that’s the real value.

Limit, Pull, Discuss

With a limited backlog, work moves forward efficiently:

🔹 Engineers pull work as they finish tasks, opening slots for new items.
🔹 Product managers must justify new additions—if something goes in, something else must come out.
🔹 Discussions happen in real-time instead of deferring decisions for months.

This approach keeps priorities fresh, avoids wasted effort, and ensures you only work on what truly matters now. There are other approaches from ours, of course (we keep improving it continuously, anyway 😀) - the main point is that you shouldn’t have a long backlog of items you will never work, even worse if you describe them in details.

So next time you’re drowning in a sea of backlog items, try this radical approach: No backlog, no problem.

Until next time, happy coding! 🤓👩‍💻👨‍💻

---

🇮🇹 Calling my Italian readers!

🚀 Want to master Continuous Integration and safely hide work in progress?

Join my hands-on Mastering CI: Fast Releases for Modern Team Workshop, organized in collaboration with Crafted Software Community, where you'll learn to implement these techniques in real-world projects. Say goodbye to long-lived branches and risky deployments—embrace seamless integration with confidence!

🎟️ Spots are limited—Sign up now and take your development workflow to the next level! 🚀

---

Until next time, happy coding! 🤓👩‍💻👨‍💻