An overflowing backlog gives you the illusion of work that’s well prepared. In reality, it’s usually the opposite: a mountain of Epics, Features, and User Stories meticulously estimated, organized, and planned out over weeks or even months, only to end up, in most cases, sleeping at the bottom of Jira. This invisible inventory isn’t a reserve of value. It’s waste piling up. And Lean Management has a name for it: overproduction Muda.
Most of the Kanban boards you come across day to day don’t actually apply the real Kanban system. They borrow its look (columns, cards you move around), but not its founding principle. The result: instead of regulating flow, they become a major source of Muda.
Why the backlog is a problem
A backlog rests entirely on a bet: the bet on a future we believe we can describe in advance. Just like estimates, it’s grounded in an uncertain future. Filling a backlog therefore means producing specs, breakdowns, and decisions for needs that don’t yet exist, in other words, practicing overproduction, one of the eight Mudas identified by Lean.
Overproduction isn’t a neutral kind of waste. It triggers a chain reaction. It generates excessive inventory, and that inventory in turn drives the obsolescence of whatever it holds, and so a gradual loss of efficiency.
In software, where evolution is fast and contexts shift quickly, this mechanism is especially critical. The ability to react fast while maintaining high quality is one of the key factors in a product’s success. And a massive backlog runs exactly counter to that agility.
The fatal gap between definition and delivery
The real danger lies in the time that separates the moment an item is defined from the moment it actually starts being delivered. During that interval, the world keeps turning: new needs emerge, specs get sharper or contradict each other, constraints appear. All of this forces you, when the time comes, to reconsider technical choices that seemed settled.
Two outcomes present themselves then, neither of them satisfying:
- At best, you partially, or entirely, rework the spec to bring it up to date before you can move forward. The initial prep work is largely lost.
- At worst, the topic is never addressed and ends up in the depths of Jira, taking with it the time and resources that went into preparing it.
In both cases, the effort invested upfront produces no value. That’s precisely the signature of overproduction: you built something nobody needed yet, and that may never be consumed.
Just-in-Time, an ally to both customer and team satisfaction
Just-in-Time (JIT), a principle from Lean Management, offers a radical answer to this problem. Rather than stockpiling work in anticipation, it consists of optimizing production by focusing on immediate value additions, pulled by the real demands of customers. The goal: foster responsiveness and efficiency by producing only what’s necessary, at the moment it’s necessary.
Pull flow rather than push
With JIT, an action is only initiated when two conditions are met:
- The need genuinely emerges. The customer has expressed a concrete, identified demand. We then say the flow is pulled (by demand), and not pushed (by speculative upfront planning).
- There’s bandwidth on the production side. The team actually has the capacity to handle the topic, rather than piling it onto an already saturated stack.
This dual condition changes everything: instead of filling inventory in anticipation, you trigger delivery as close as possible to the real need and the available capacity.
The concrete benefits
Aligning production with demand this way produces three direct effects:
- Reduced Lead Time. By delivering value immediately on an identified need, you drastically shorten the delay between the expression of a need and its fulfillment. No more waiting in intermediate inventory.
- Less pressure on the operator. By avoiding the constant context switch imposed by a multitude of open topics, you let everyone focus on a single objective at a time, which improves both quality and the comfort of work.
- Better visibility into problems. Inventory tends to hide quality defects and inefficiencies in a flow. By removing it, JIT lays these problems bare and makes them addressable.
The natural consequence of all this: a simultaneous improvement in customer satisfaction and team satisfaction. The two aren’t at odds: they advance together.
Quality and efficiency aren’t at odds
This is probably Lean’s most counterintuitive lesson, and the most important to remember. We often pit quality against efficiency, as if you had to sacrifice one to gain the other. Lean demonstrates the opposite: by removing waste (and the overproduction of a backlog is a major form of it), you improve both quality and efficiency at once.
Adopting Just-in-Time, then, isn’t just about emptying a cluttered backlog. It’s about changing the very logic of production: moving from a system that pushes speculative work toward teams to a system that pulls value from real need. Less inventory, less obsolescence, less rework, and ultimately, a product that responds faster and better to what its users actually expect.