Upstream Kanban: Handling Requests Before You Commit to Them

Introduction

Open the backlog of any team that has run for two years and count the items. Four hundred is normal. Now ask a harder question about each one: did anybody actually decide to do this? For most, the answer is no. Somebody mentioned it in a call, somebody filed it after a support ticket, somebody had an idea on a Friday. None of that is a decision, and all of it sits alongside work the team genuinely promised to deliver.

That is a vocabulary problem before it is a process problem. The word "backlog" does two unrelated jobs: it names the things we have committed to finishing, and it names the things that have been said out loud. Keeping both in one list means the list cannot be trusted, so nobody reads past the top ten, and the other three hundred and ninety exist only to make everyone feel behind.

Upstream kanban is the practice of managing the second set deliberately, as its own queue with its own rules. The term comes from the Kanban community, where "downstream" is the work in flight and "upstream" is everything not yet committed to. The idea is simpler than the vocabulary: a request needs somewhere to wait that is not the same place as a promise.

An Option Is Not a Commitment

The useful distinction is borrowed from finance and survives the translation. An option is the right to do something later: cheap to hold, costly to exercise. A commitment is a promise that a specific thing will be finished.

Between those two states there is a moment that deserves a name: the commitment point. Before it, an item is a candidate. After it, the team owns the outcome. Most tools have no commitment point at all, because creating a ticket is the only act available. Creating is committing, so a sentence in a meeting becomes a line in the delivery plan with no decision in between.

Why Deferring the Commitment Pays

Information arrives over time. A request made in March looks different in June, after four more people asked for something adjacent, or after nobody mentioned it again. Deciding in June costs nothing extra and uses more information. Deciding in March means guessing, then defending the guess.

Commitment consumes capacity. A committed item is work in progress whether or not anyone has touched it: it occupies attention, status updates and queue position. Average cycle time is work in progress divided by throughput, as Little's Law sets out, so a committed queue that outruns delivery slows everything in it, including the items that matter.

An abandoned commitment is pure loss. Drop a committed item after six months and you do not get those six months back: it was triaged repeatedly, it aged visibly, and item age makes that cost impossible to hide. An option never exercised costs almost nothing. That asymmetry is the whole argument.

One caveat, because it is the failure mode of the idea: deferring a commitment is not the same as never deciding. An upstream queue that nothing ever leaves is worse than no queue at all, since it teaches everyone that submitting a request is theatre.

Two Queues, Side by Side

The row that changes behaviour is the fifth. Upstream wants to be generous, because holding an option is cheap and discarding a request you will need in a year is not. Downstream wants to be mean, for the reason a work in progress limit exists. One queue cannot be both.

What Has to Happen at the Commitment Point

A commitment point is only real if something observable happens when an item crosses it. Three things, in practice.

The decision has more than two outcomes. Yes and no are not enough, because most requests are neither. Four is about right: take it, turn it down, send it back because there is not enough to judge, or park it as a genuine maybe. Collapsing four into two is what produces a backlog of items that were never really accepted.

The reason is recorded where the requester can see it. A turned-down request with a written reason ends an argument. One that silently stops moving starts one, usually three weeks later, in public.

Commitment happens at the rate of delivery, not the rate of arrival. This is the replenishment rule, and the same idea as a pull system: you commit when the committed queue has room, not when a request shows up. Requests arrive at whatever rate the world chooses. Throughput is a property of your team. Letting the first set the second is how a queue becomes a graveyard.

Where Intake Goes Wrong on Small Teams

No upstream queue at all. The default. Everything lands in one list, the list is mostly noise, the ordering is not trusted, and people negotiate priority in chat instead. A second place for things to live is nearly the whole fix.

An upstream queue with no review cadence. More demoralising. Ideas go in, nothing comes out, and within two months nobody submits anything because submitting is visibly pointless. Twenty minutes every other week is enough at this size.

Running upstream like a second project plan. Estimating options, assigning owners, grooming them in a long meeting. The expensive mistake, because it looks like diligence. Options do not need estimates. They need to be findable, countable and occasionally decided about.

Saying yes at the door. "Sure, we can add that" on a client call is a commitment made at the moment of minimum information, by the person who will not pay for it. The upstream queue exists so there is a kind thing to say instead: it is captured, it gets reviewed Thursday, you will hear the outcome.

How This Works in FlowBoard

FlowBoard has one continuous flow, a single prioritised list with no columns and no sprint containers. That is the downstream queue, and the point of it is that everything in it is genuinely committed.

Upstream is a separate board. Ideas live on their own board, not in the flow, so an idea cannot be picked up by accident, cannot be attached to a release, and does not sit between the team and the work it has promised. Two places, by construction.

Reviewing an idea offers the four outcomes above rather than two: accept it, reject it with a reason, send it back for rework with a note saying what is missing, or discard it. Reject and rework both write the reason onto the idea as a comment, so the record of why travels with the item. A rejected idea can be reopened later, because an option turned down in March is not wrong forever.

The commitment point is one explicit action: moving an accepted idea into the main flow. That is when it changes board, becomes open work and joins the prioritised list. Before it, the item is not in your delivery queue in any sense. The acceptance timestamp carries across, so the gap between "we said yes" and "we started" is visible rather than folklore.

Demand gets measured without becoming a decision. Ideas carry votes and record who voted, so five people asking for the same thing is a number you see at review time rather than an impression. Requests from outside the team arrive through a public submission form that drops onto the ideas board at a neutral priority score with no release attached: an external request cannot enter the committed flow merely by arriving.

At volume, review itself becomes the bottleneck, and that is the part worth automating. An AI product owner can read the queue, flag duplicates and recommend accept, reject or rework, then wait for a person to confirm. The recommendation is cheap, the commitment stays human.

Deliberately missing: no grooming ceremony, no estimation pass, no workflow to configure first. The upstream queue is a board and a habit.

Frequently Asked Questions

What is upstream kanban?

Upstream kanban is the practice of managing requests before they are committed to, as a separate queue with its own rules. Downstream is the work in flight, which needs strict ordering and tight limits. Upstream is everything only suggested so far, which needs capture, visibility and a regular decision, but no estimates and no promises.

What is a commitment point?

The commitment point is the single observable moment when an option becomes a promise. Before it, dropping an item costs nothing. After it, the team owns the outcome and somebody is waiting. A process with no explicit commitment point commits to everything the instant it is written down, which is why so many backlogs are full of work nobody decided to do.

How often should a small team review the upstream queue?

Every one or two weeks, for about twenty minutes, is enough for a team under fifteen people. The cadence matters more than the duration: a short review that reliably happens beats a thorough one that slips, because what is being protected is the requester's belief that submitting something leads to an answer.

Should you tell someone their request was rejected?

Yes, and the reason matters more than the verdict. Silence does not reject a request, it defers it indefinitely while leaving the requester to assume it is still coming, which is how the same idea arrives four more times. Recording the reason on the item itself makes this cheap enough to actually do.

What to Do This Week

You do not need a new process, just one pass over the list you already have. Go down your backlog and mark each item with one of two letters: C if the team genuinely decided to do it, O if somebody merely said it. Do not refine, estimate or reorder. Most teams find between fifteen and forty C items, and that is the discovery: the real committed queue was always small, hidden inside a list ten times its size.

Then move every O somewhere else, pick a day every other week to review them, and tell the people who ask you for things that the day exists. That is upstream kanban.

Next: how to run the pipeline once both queues exist, and classes of service, for the request that genuinely cannot wait for Thursday.