#NoBacklog
The typical backlog is a tech task tracker, a bug database, or a feature wishlist. Ultimately, it’s a black hole of promises, wasted work, and a source of frustration.
We only need the user stories in progress and a few more ahead, which can be discarded anytime. That’s our backlog, if you want to call it such. I’ll tell you why and how. This advice follows The “Just Sharing” Principle.
Expectation management
How many stories do you have on the backlog, and what’s its growth rate? What’s their average lead time (problem-identified to solution-delivered time)? A backlog that keeps piling up is an anchor weighing down the team’s spirit. It feels like we are not able to do our jobs. Think how helpless you feel when faced with hundreds of stories for months because you kept doing other, more important things. The current stories keep being pushed forward, forever on the back burner, while more stories are added daily. It grows to infinite.
Backlogs are a big weight we don’t need to carry. Dozens and eventually hundreds of tasks pile up that we all know we’ll never have time for. The growing pile gives us a feeling like we’re always behind even though we’re not. Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again. Shape Up
Besides being a source of frustration and anxiety, backlogs also create false expectations. People, especially outside of the team, believe you’ll get those stories done at some point (you won’t). A backlog full of stories is a backlog full of lies. At best, it’s a wishlist; at worst, we’re in denial, deceiving ourselves and the ones around us. You may think a backlog is a look into the future, but it’s just a piece of archeology.
Waste
How often do you bump into stories that don’t make sense anymore? How long do you spend preparing each user story? Reflect on the hours wasted updating dozens of stories, most of which will never be picked up. Think about all the discussions, describing scenarios, defining acceptance criteria, adding details, labeling, preparing UI mockups, estimating, splitting, and prioritizing. Putting in all that effort attaches you to the wrong things — the process and the tool. Focus on the outcomes instead. Could you redirect all the effort to the present? Into discovery, user research, splitting stories, reprioritizing, and actively understanding the impact of what you just did. One of the lean principles is eliminating waste — the backlog is the inventory type of waste.
Backlogs are big time wasters too. The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now. Shape Up
A backlog biases the team’s work to what was decided weeks or months before while the world kept spinning. The mere passage of time can make most of your backlog irrelevant or obsolete. The team is possibly running behind outdated goals, putting a lot of effort into implementing solutions that no longer solve real problems. This is backlog-driven development, where the backlog becomes the goal. Stories are like vegetables… you have little time to consume them, or they will rot, so you buy as you need; you keep the stock low.
I’ve observed managers handling the backlog like it was their child. They kept refining backlogs worth a quarter of a year’s work. How can you prioritize a backlog with so many stories? It’s a daunting endeavor, if not humanely impossible. Some product managers prune their backlogs and start anew because most tickets are obsolete. They do this spring cleaning now and then, the rationale being that if something is important, it will come up again, or else it’s pointless. That’s a good idea, but they should address the root cause rather than the symptom. Why did they waste so much time writing the stories in the first place only to be deleted? If the team won’t ever get to those dozens of stories on the horizon, why bother detailing them?
Simplicity — the art of maximizing the amount of work not done — is essential. Agile Manifesto
Continuous discovery
According to the definition, a backlog is a reserve of work. Work is decided and prepared upfront, which you execute following FIFO (in such a predictable environment, adding more people increases the speed of delivery, unlike in software). This is great for assembly lines but not for software development, where it’s a clear instance of waterfall thinking.
The fact is that we don’t work in a factory. In software, a backlog is an inglorious prediction of what we’ll solve in the upcoming weeks and months (i.e., a long-term plan), but time and time again, our attempts to predict the future lead to waste.
Product development is not a linear path where we already know what we will do afterward, and we need to follow the plan, like building a house. Rather, we must navigate the waters based on new information that we receive along the way. We only know what to do after delivering the current story and getting feedback; acting on that feedback feeds the following work. Every delivered story is a small increment of value — there’s a new product with every iteration, and that’s always our new starting point. It’s a continuous process of discovery. It’s a journey of constant learning and adapting.
Working without a plan may seem scary. But blindly following a plan that has no relationship with reality is even scarier. Rework
A 2-month-old story was created and detailed when we knew much less than we know today. Stories in a backlog represent decisions made without the necessary feedback. We should execute an infinite cycle of deploying and gathering feedback (CI/CD) to make better decisions. Our mental model of the domain is iterated and restructured as we learn. If that’s not happening, we’re likely lacking feedback mechanisms. On the other hand, the word also changes: we may discover that a problem doesn’t exist anymore because the users’ needs or journeys have mutated. The act of delivering also shuffles the priorities. For example, the users may be happy with the first iteration, and we move on to something else.
In short, creating numerous user stories in advance reveals a lack of humility in acknowledging our inability to foresee the future and the consequences of our actions. Defining work upfront is the wrong way to deal with the world’s uncertainty. The context changes too often. A product backlog is a fragile artifact by definition. You either put effort into maintaining it or let it become outdated, but neither is ideal.
Towards no backlog
Why do you need a backlog? What’s your trigger to add a story? What’s its return on investment? What problem are you trying to solve with a backlog? Are there other ways to solve it? My opinion is that you can forget the backlog. An endlessly expanding backlog serves no practical purpose. All you need is a board with a few stories representing the work in progress (problems being solved) and the next hypothetical problems to tackle. We should strive for a “zero-backlog” approach, adding stories as needed and keeping our minds unbiased. While having a few stories ahead is okay, we should avoid adding and detailing stories we’ll never do. It’s about not deceiving everyone with plans and promises. It’s about being open to constant steering, swiftly discarding whatever gets old.
📝 A user story is simply a placeholder for a user problem; solutions and details are only relevant when starting the work (last responsible moment) if the work is ever started. Separating planning and execution is Taylorism, which does not apply to software development.
User stories should fit on a post-it as they represent a user problem. Focus on the most pressing issues and potential added value and adjust often. Since we know our next work as we discover it, creating stories should be cheap (i.e., to have a negligible overhead) so that we can create them without attachment and discard them without pain. Preferably, create stories on the fly, with the maximum context available. This lightweight process fosters a culture of experimentation and continuous discovery. Having very few stories and creating them as we go is how we embrace the inherent uncertainty of the world.
A small board reduces the team’s frustration because they stop seeing a mountain of work ahead and start focusing on what’s being done and what needs to be done. It fits on your screen and in your mind. A small board encourages constant story splitting (knowing that we’re doing small increments with value), reprioritization (ensuring we’re always working on the most important thing), and cleaning (no backlog-driven development). Finally, we stop making false promises to everyone, and they can see our current and following focus (and can influence it).
📝 A no-backlog approach aligns with the Build - Measure - Learn (BML) cycle, a fundamental concept in The Lean Startup methodology. It involves building a minimum viable product (MVP), measuring its performance, gathering data, and continuously using this information to learn and iterate. Despite its origins, BML shouldn’t be seen as only applicable to startup products.
Common questions
How do I track the desired features? How commonly do you hear, “Don’t worry, it’s in the backlog!” like that did anything good to solve it… It’s just a lie. Always understand the problem behind a request — that’s what is on your board. The goal is not to add features but to solve problems. Beware of featuritis; if you already have a never-ending list of features in a backlog, convert them to real user problems, order them by importance, and trim them down to a few. Rest assured that anything important will pop up again.
What about predictability? You should aim for a team that can easily adapt to feedback instead of sticking to a predictable plan. You should educate your customers and users to expect a continuous flow of value rather than a predetermined list of features agreed upon months before when everything was cloudy. Instead of working to check off boxes, focus on solving the most pressing issues daily.
But I need to track all the refactorings! The board/backlog is not a way to track technical tasks such as refactorings. It’s not a developer tool; it’s a team tool, and everyone should understand it. Technical tasks/chores belong to real user stories that you have on the board (surely, sometimes there are technical tasks that serve no user story, but that’s the exception, not the rule). Refactorings, in particular, should be done when executing the story and triggered by an actual need rather than by pure whim or running behind — with all the context at hand.
How do I track bugs? What good does a bug report with a promise of months do to anyone? Won’t it be just gathering dust? What’s the point of solving a problem a year after being identified? When (if) you finally get to it, does it still exist? Is it still a problem? Won’t a product that is loaded with features but plagued with bugs eventually cost more in the long run? If a bug is important, fix it immediately (after finishing the work in progress, of course). This promotes a no-bugs culture where you implement the necessary assurances to prevent them from existing in the first place (e.g., lean dev., prioritizing bug fixing before building new stuff, better safety nets, CI/CD thinking). Having no bugs may seem impossible, but continuously trying is what matters the most.
What if my domain is stable, and I know what to do months ahead? Things may not be as stable as you think. We must be humble and open-minded to acknowledge that we can’t know tomorrow because what we did today will irrevocably change it. Why not keep the options open? What problem are we solving with a detailed backlog? What is lost by not creating too many stories in advance and doing it at the last responsible moment with the latest knowledge? Why outright reject the possibility of adjusting often? Isn’t that the best way to ensure we aren’t building the wrong thing to please a plan? Isn’t that the best way to strip away all the bias from the past?
What about the ideas that we keep having? Should I ignore them? A backlog is not a dumpster of ideas (nor a cemetery). It represents the team’s focus on real users’ needs (hence, they’re called user stories). A long list of random ideas obfuscates the real problems, especially if the ideas are internal requests. Not all ideas are valuable, worth it, or feasible, so you should consider an alternate way to triage and track them.
