Just-in-Time Development

Most teams build their backlog, the queue of work waiting to be built, like a warehouse. Stack it high, keep it full, never run out of work. A six-month plan, groomed in detail, every item written up and estimated and sitting in a row waiting its turn.

It looks like preparation. It's the opposite. It's a pile of guesses you committed to before you knew enough to make them.

Just-in-time development is the fix. You refine and build work right before you need it, in small scoped pieces, instead of stockpiling a planned backlog that rots before anyone touches it. Refining is the work of writing an item up in detail, sizing it, and breaking it into pieces a team can actually build. So you do that work, and the build, right when the item comes up, not months ahead. Pull the next right thing through. Don't push a year of plans into a queue and call it a strategy.

Where this comes from

This isn't a software idea. It's a manufacturing one, and it's older than most of the methods in this section.

Taiichi Ohno built the Toyota Production System around it. The principle was simple and it broke how factories had run for decades: don't make a part until the next step actually needs it. Pull, don't push. Keep inventory low. Build in small batches instead of giant runs.

The reason was money. Inventory is cash sitting still. A warehouse full of finished parts is capital you've spent on something nobody has bought yet, and the longer it sits, the more it costs you to store it, track it, and eventually throw it away when the design changes. So Toyota stopped building ahead. They built to demand, in small pulls, just in time.

Now swap "parts" for "product work" and read it again. A backlog stuffed with detailed, planned, estimated work is inventory. You spent real hours building it. It sits there. And it costs you, because the longer it waits, the more the world moves out from under it, until the day you finally build it and it solves a problem nobody has anymore.

The factory's lesson is the product team's lesson. Inventory rots.

What it looks like in product

You already saw the shape of this back in the Opportunity Backlog. When a solution earns enough confidence to build, it lands on the product backlog, which I called a just-in-time list of validated solutions. A validated solution is one you've tested enough to believe it'll actually work, not just one somebody got excited about. And that phrase, just-in-time, was doing real work. The backlog isn't a stockpile of everything you might ever build. It's the next validated solutions, queued in priority order, refined right before a team picks them up.

Here's the flow end to end.

Discovery surfaces problems worth solving. The discovery loop, the build-test-learn cycle you run before you commit, validates a solution by proving it'll work. The validated solution enters the product backlog. It gets refined into real work just before a team builds it. The team builds it small, ships it, and the results pull the next thing forward.

Notice what's missing. There's no point in that flow where you write up six months of detailed work in advance. You write up the next thing, in detail, when it's almost its turn. The item three months out stays a one-line problem statement until it's close, because anything you write in detail now will be wrong by the time you get to it.

This is the part teams fight. They want the whole backlog filled in and estimated so it feels under control. But a deep, detailed backlog isn't control. It's a guarantee you'll be wrong across the whole backlog at once. The more of it you write ahead of the work, the more of it you'll throw away.

So refine just before you build. Keep the work small. Pull the next item when the last one ships. That's just-in-time development.

Why small is the whole point

Small isn't a style choice. It's the mechanism that makes the pull work, and it's the thread running through this entire section.

Here's the proof. I've only seen one company deliver real things on time off a roadmap, and the reason it worked was that the work was scoped to such a small size you could deliver it with real accuracy. Not bundled into giant quarterly releases. Managed in a just-in-time manner, small piece by small piece. That's not a coincidence.

Estimation is where the size shows up first. A small thing has fewer ways to surprise you, so you can size it with some accuracy and refine it fast right before you build it. A six-month epic has a thousand ways to surprise you, so you can't size it honestly, which means the date is a fantasy and the detailed plan you wrote for it is a guess you'll throw away. Small lets you be right about the work. Big forces you to lie about it.

And small is what lets you ship and learn, because a small piece is something you can actually get in front of a customer instead of waiting on a giant release. That's the part that matters most, and it's the whole subject of the next section.

Small is what lets you pull. Big is what forces you to push.

This is how you stay empirical

Just-in-time isn't only an efficiency play. It's what keeps the whole thing honest.

Agile lives or dies on empiricism, which just means you let real-world results, not the plan, decide what you do next. In practice that's a loop: you release small, you watch what real customers actually do, and the results pick the next move. If you don't release to your customer, you can't be empirical, because there are no real results to learn from. That's the non-negotiable, and it runs straight back to the first principle in the Agile Manifesto (agilemanifesto.org): satisfy the customer through early and continuous delivery.

You can't do that off a stockpiled backlog.

A pile of pre-planned work tells the team the job is to deliver the list. Head down, build the next item, build the one after that, never stopping to ask whether the last thing you shipped actually worked. The plan becomes the master. Real-world results become an interruption.

Just-in-time flips it. The results are the input. You build a small piece, you ship it, you see what happened, and that outcome decides what gets pulled next. The backlog stays thin on purpose, because you don't want to commit the next ten things before you've learned from this one.

This is also why you don't commit to a dated plan in the first place. If you want that argument in full, go back to Why No Product Roadmaps. The short version: dates plus a title equals a commitment, and a commitment made before you've learned anything is a commitment to be wrong on schedule. Just-in-time is the delivery habit that keeps you from making it.

The failure mode I've watched everywhere

I don't have one dramatic war story for this. I have the opposite, which is worse: it's the standard at nearly every place I've worked.

It goes like this. A backlog fills up with unvalidated items, the hot item of the minute, the thing everybody got excited about in a meeting. Each one gets manicured. Written up, estimated, planned in detail, dressed up so it looks like real work. Then it sits.

And then it gets shelved. An executive turns over and the new one has different priorities, so the old hot items get quietly dropped for the new hot items. Or a news article points at some new technology and suddenly that's the thing the whole roadmap has to be about, and last quarter's manicured backlog is dead weight nobody will admit to.

So the cycle starts over. New hot items, manicured and planned, headed for the same shelf.

Watch what got burned. Not just the build time, because most of it never got built. The planning time. All those hours writing up, estimating, and grooming work that was never validated and never shipped. That's the inventory cost made real. You paid to build a warehouse of plans, and the plans expired on the shelf.

And here's the part most people miss, because it's easier to blame the executive who turned over or the article that moved the goalposts. The backlog churns like that because there's no strategy underneath it.

When you have a real strategy, you have a way to tell a problem worth solving from a shiny distraction, so a news article can't hijack the roadmap and an exec swap can't reset it to zero. When you don't, every loud idea looks equally valid, so the backlog just tracks whoever shouted last. A stockpiled backlog full of unvalidated hot items isn't a planning problem you can fix with better grooming. It's a strategy problem wearing a planning problem's clothes.

Just-in-time development won't save you from that. Nothing on the delivery side will. It's a symptom, and the cause sits upstream in your vision and strategy, back in Parts 02 and 03. But a thin, just-in-time backlog makes the problem impossible to hide. You can't stockpile a hundred unvalidated guesses and call it progress when the rule is that nothing gets written in detail until it's validated and almost its turn to build.

How it shows up day to day

You don't install just-in-time. You practice it, in the small choices about when you refine work and how much of it you hold open at once.

Refine just before you build. Hold detailed refinement for the work that's actually coming up next, not the stuff three months out. The next sprint or two, a sprint being a short work cycle, often a week or two, gets written up properly. Everything past that stays a problem statement and a rough size until it gets close.

Keep batches small. The smaller each piece, the more honestly just-in-time works, because small work is what you can refine late, estimate well, and ship to learn from. Sizing the pieces down to that grain is the job of the writing guides that follow this page: big chunks broken into smaller and smaller pieces, epics (a large feature) into stories (one user-facing piece), stories into tasks small enough to finish in a day.

Cap the work in progress. Pull the next item when the last one ships, not before. If you're running kanban, the board where work moves across columns one card at a time, that cap is literally built into the method as the limit on how many cards can be in progress at once. For the mechanics, the Agile page walks through them. The instinct is the same one Ohno had on the factory floor: don't start the next thing until the last thing moves.

A full warehouse feels safe. It isn't. Build a thin backlog, refine it late, ship it small, and let the results pull the next thing forward. Do it the other way and you'll spend your hours stocking shelves with plans that expire before anyone builds them. That's not preparation. It's just inventory, waiting to rot.