Upstream & Discovery Kanban

1. What is upstream Kanban?

Conventional Kanban implementations focus on work approved for delivery, turning it into Kanban tasks when ready for execution. But Kanban can go beyond that. Decisions taken before the Ready for delivery point define what enters the delivery system, how much uncertainty the work carries for the engineering team, and whether they’re solving the right problems. In other words, waste most likely occurs prior to developers getting started on delivery.

Upstream and discovery Kanban stretches flow management to pre-delivery stages.
It illustrates potential work, limits the allowed number of opportunities to investigate at once, and defines explicit conditions for deciding what comes next in the broader process.

Upstream Kanban controls the flow of options and choices that lead to delivery commitments.

This is a problem upstream of delivery: there are more potential tasks than it’s possible to look into, and a solid mechanism for choosing requests is missing.

Upstream work includes:

• Discovery: Understanding the nature and scope of a problem, and learning the circumstances under which it presents.
• Research: Collecting customer feedback, analyzing operational data and existing solutions, as well as predicting technical constraints.
• Validation: Verifying that a suggested solution addresses an evident need, and that the effort required to implement it does not outweigh the potential benefits.
• Analysis: Estimating risk, cost, value, dependencies, and alignment with broader priorities.
• Readiness: Finding sufficient clarity of the intended outcome for delivery work to begin.

Of course, the required activities and team members will vary depending on context.
A product team might look into a feature request, while an IT service specialist may diagnose an incident before approving permanent changes. In terms of types of activities/tasks in upstream Kanban, it’s usually helpful to differentiate between ideas (not yet evaluated), investigations (being actively analyzed), and commitments (selected for execution).

Because these activity categories highlight different levels of commitment, they shouldn’t be treated interchangeably, just as in any Kanban workflow.

2. Mapping the flow from idea to delivery

An example upstream workflow might contain these states:

The proposed labels describe all possible states, not a mandatory process.

A small request can be analyzed and rejected at Triage, while a broad opportunity can revert to Research after initial validation. Items can also be deferred or parked in Research due to a pending dependency or inappropriate timing/circumstances.

On the other hand, the upstream flow should be reflective of how decisions are actually made in the organization; creating stages for actions that never happen, or artificially splitting steps impossible to distinguish meaningfully, adds administrative overhead without adding value.

Regardless of layout, the board must clearly visualize each opportunity’s present state, the next required decisions, and any known impediments.

Mapping the upstream flow makes it easier to challenge assumptions before committing to costly ad-hoc changes that may or may not be solving underlying problems.

3. Controlling upstream WIP

Individual investigations progress slowly when there’s no cap on their concurrent volume. Decisions aren’t made in time, and accumulated research may become outdated before it’s used. Therefore, it’s crucial to apply WIP limits to actively analyzed ideas, not just to actively developed solutions in delivery.

When the limit is met, the team should huddle to complete one of the open investigations or reach a different conclusive decision about it (e.g., park or delete it), before starting a new one. And if - in justified circumstances - the limit is exceeded, the team should make the trade-off explicit to others, not just quietly add more work.

Finding an appropriate limit depends on the kind of work, the availability of specialists, the time needed to gather evidence, and the team’s general ability and experience in completing analysis.

Limiting discovery WIP makes room for focused investigation. For deeper explanation, read more about WIP limits, Pull Systems, and Queuing Theory.

4. Defining policies, entry and decision criteria

Before an opportunity enters the Discovery stage and moves on to the rest of the upstream process, it may need to list specific pieces of information, since requests lacking details crucial to analysis are likely to remain in Triage (and block it) while the missing data is gathered.

Use explicit policies for each upstream process step. State what qualifies an idea for investigation, what end data an investigation must produce, and how the resulting data is to be used.

Strict entry/exit criteria applied to appropriate columns of the upstream Kanban provide tangible readiness thresholds, without requiring every detail of the final delivery to be named in advance.

The same applies to decision rights. Product management reps might own prioritization, while design, research, engineering, security, or operations teams provide evidence within their set areas of knowledge and responsibility. Relevant stakeholders contribute input visibly - on the specific task card- making the team aware of who is accountable for reaching which decision.

Lastly, the possible outcomes should be equally clear, e.g.:

• Go ahead: The evidence supports promoting the opportunity to delivery.
• Investigate further: A specific unanswered question justifies additional work.
• Defer: The opportunity is valuable, but other work takes precedence, or other conditions prevent taking it on.
• Reject: The evidence does not justify further investment.

Importantly, recording the reason for each decision may prevent already rejected ideas from returning, and deferred ideas should list conditions for their reconsideration rather than remain in the unattended queue indefinitely.

If different request types require different treatment, such as a time-critical regulatory change or an urgent operational issue, consider using Classes of Service, keeping in mind that handling urgencies should be defined by explicit policy, not allowing every stakeholder to bypass the queue.

5. Managing uncertainty

Discovery work differs from delivery in that the outcome is uncertain: you may know the question that needs answering, but can neither guess how long the investigation will take, nor what the evidence will show in the end. It therefore cannot be managed like a delivery flow. Treating it as such may result in premature planning and waste; a team may spend weeks on detailed specification for a solution whose broad assumptions weren’t verified.
The desired approach is to identify the biggest uncertainty and investigate that directly.

Practices to keep discovery focused:

• Time-box analysis when useful/possible.
  A due date for investigations creates a review point, limiting never-ending examination and interviews.
• Break wide questions into smaller investigations.
  Smaller unknowns are easier to investigate, and can eliminate unnecessary work early.
• Test assumptions cheaply.
  Keep interviews, data analysis, prototypes, and simulation scope small. Size-limited operational trials provide useful evidence before jumping to a full implementation.
• Allow evidence to disprove the idea.
  An investigation that reveals wrong assumptions, weak demand, or costs beyond budget is still useful, even when the opportunity is rejected.
• Avoid suggesting solutions too early.
  Define enough to understand and explain the problem and assess the risks, but leave implementation specifics out, as further data or technical exploration can impact the solution.

Notably, not every investigation calls for time-boxing, and not all assumptions can be checked with a quick, cheap experiment; some work requires extended research, specialist analysis, extra approvals, or even a regulatory review. The goal of an upstream Kanban is to make uncertainty visible and let the team select investigations adequate to cost, risk, value and all other circumstances.

6. Measure upstream flow

Once visible, the team can measure how upstream work moves to identify where decisions are delayed. For best results, analyze both the flow of investigations and the quality of their produced outcomes.

• Time to decision: how long it takes from a defined starting point, e.g., an opportunity entering Discovery, to an outcome being recorded.
  Total wait from request submission should be measured separately if needed.
• Upstream WIP: the number of investigations active at a given time. Increasing WIP coinciding with growing decision times may indicate the team is starting more work than it is able to complete. Importantly, the analysis should account for the type/complexity of the investigations.
• Queue age: how long an opportunity has been waiting without attention or progress. An aging queue may show that requests are building up faster than the team can get to them, or that some work lacks a clear owner.
• Decision throughput: how many opportunities reach an outcome (whatever it may be) over a set time.
• Outcome quality: whether discovery meaningfully decreased uncertainty and improved subsequent decisions. Signals considered for this measurement include: fewer delivery changes due to misunderstood requirements, fewer dropped implementations, or proof that rejected opportunity value would have consumed disproportionate effort.

Keep in mind that decision throughput alone isn’t a reliable measure of success, since a team that approves opportunities quickly and in high volume may simply have applied weak criteria, and an early rejection of a poorly supported concept can be more meaningful/valuable than approving several ideas that later prove unsuitable.

As with all process metrics, they should inform and inspire questions about the system, rather than turning into targets, generating undesirable practices to meet them at any cost. If time to decision grows, check if the cause isn’t excessive WIP, missing information on tasks, delayed feedback, or unknown decision authority. And if queue age increases, look at intake capacity and prioritization rules. The goal is always understanding the constraint and solving it to improve the flow.

For more information on finding and addressing constraints, please read Bottlenecks.
In cases where sufficient historical data is on hand, Statistical Forecasting could help in estimating decision times or the potential completion of a type of an investigation. Notably, forecasts must reflect observed variability and the work type under consideration; they won’t remove uncertainty from discovery.

7. Connecting upstream and delivery Kanban

Upstream Kanban is most useful when directly connected to the delivery Kanban, since decisions and feedback pass between them regardless. But the transition between them should be clear, with defined delivery entry criteria and a singular definition of “approval”.

The connected upstream and downstream team may keep a small buffer of validated work: a selection of opportunities understood well enough for picking up when capacity arises. But the buffer size should remain relative to delivery capacity and the rate of priority changes.
You don’t want a buffer too big, because approved items could end up waiting longer than their assumptions are valid for, while - at the same time - engineering will face pressure to pick up that work simply because it’s already there.
Validation of assumptions and opportunities does not guarantee value delivery, so a task getting to the Ready queue should not be treated as a promise of delivery.
The team should therefore gauge how many items ready for delivery they need in the first place, and periodically review aging items, replenishing the delivery queue in line with actual capacity and priorities. There’s no point in flooding engineering with more approved work than it can handle.

And feedback must travel in the opposite direction, too. The delivery team members may bring information on tech constraints, dependencies, updated implementation costs, or user behavior that alters the original assessment, directly influencing upstream priorities.

Coordination between upstream and delivery - including product, design, research, and engineering - should revolve around the information required for decision-making. Handoffs can be reduced by agreeing on shared flow policies, holding regular replenishment discussions, and encouraging direct collaboration. The latter includes establishing how to flag impediments, such as marking a task as blocked and leaving a comment for its owner.

The combined flow

The following diagram maps how upstream and downstream Kanban systems may connect within a software team. As before, it lists possible states; not all tasks have to pass through all of them.

The merging of the two Kanban workflows can be thought of as a managed decision point: upstream decides which opportunities to consider, while downstream provides evidence on whether those decisions were correct. The team should understand this relationship, but keep in mind that opportunity validation is not a delivery obligation.

Discovery Kanban extends flow management to the decisions that create delivery demand. Visualizing all opportunities, controlling ongoing investigations, sticking to decision policies, and tracking time to meeting outcomes all help teams reduce poorly understood tasks entering execution and resulting in waste.
The achieved system treats the organization’s plans and considerations just as deliberately as it treats its commitments to deliver.