Visual Requirements Management with Kanban

There is a lot of attention on what happens after requirements arrive at the delivery team. Sprints, retrospectives, story sizing, burndown charts, velocity — the whole apparatus is calibrated for the delivery half of product development.

What gets far less attention is the upstream half — the work product management does before features ever hit a backlog. And that’s where most product teams actually break.

Upstream work runs on a different cadence than delivery. Stakeholders disagree, requirements emerge, priorities shift, and the work itself doesn’t fit cleanly into a sprint. Most product organizations either pretend it does (and end up with a chaotic backlog) or treat it as Product’s problem to solve alone (and end up with delivery teams starved of well-shaped work).

This presentation provides some insights into applying Kanban — specifically visual requirements management with Kanban — to the upstream half. It’s been part of the way we work at NimbleWork for years, and the patterns transfer across most product organizations of meaningful size.

Why upstream needs its own system

The work Product Management does has three properties that delivery work doesn’t have:

• Variable cadence. Delivery teams plan in fixed cadences (2-week sprints, monthly releases). Upstream work doesn’t. Discovery takes as long as it takes, stakeholder alignment takes as long as it takes, and forcing it into a sprint usually just produces theatre.
• Multi-stakeholder input. A delivery team has a clear “input”- the backlog. Upstream work has many inputs: customers, sales, executives, support, market data, competitive intelligence. Synthesising all of those is a job in itself.
• Emergent prioritisation. Delivery teams take prioritisation as given. Product Management generates prioritisation — and it changes as the inputs change. The system has to support that, not punish it.

Standard sprint-based Agile tools handle none of these well. What works instead is Kanban. Specifically a few layered Kanban systems running at portfolio, feature, and user-story levels.

Three Kanban layers for upstream work

The mental model we’ve found most useful: think of upstream work as three nested Kanban systems, each with its own flow and policies.

Layer 1: Portfolio Kanban — the big picture.

The portfolio board shows themes and major initiatives across the product. Cards are intentionally chunky — usually 3-6 months of work. The columns reflect strategic readiness, not delivery state: Idea → Validated → Funded → In Delivery → Released → Outcome Measured.

Why this layer matters: it gives Product leaders the conversation they need at the strategy level (what are we doing, what’s in flight, what’s done, what’s coming) without forcing them to look at every user story. Done well, it replaces 80% of executive review meetings

Layer 2: Feature Kanban — the requirements layer.

This is the layer most teams skip, and it’s where most teams break. The feature board sits between portfolio and delivery, and its job is to shape requirements so they’re ready for a delivery team. Columns look something like: Concept → Customer-Validated → Story-Mapped → Estimated → Ready for Sprint.

Cards on this board are features, not stories. The columns reflect the shaping work — talking to customers, mapping stories, estimating, getting it ready. This is where Product Management does most of its actual work, and it’s exactly the work that vanishes when you only have a sprint board.

Layer 3: User Story Kanban — the delivery-ready layer.

The user story layer is where things meet the delivery system. Cards are individual stories or thin slices of features. Columns reflect Definition of Ready and Definition of Done states: Refined → Estimated → In Sprint → In Dev → In QA → Done. 

This layer overlaps with what delivery teams already do — but it works much better when it’s connected to the feature and portfolio layers above, so a story always has a parent feature, and that feature always has a parent initiative.

What gets visualised — and why it matters

Each layer makes different things visible. That’s the point.

The portfolio layer makes strategic intent visible: what we’re investing in, what’s funded, what’s at risk. Without this, executives ask “what are we working on?” in every review.

The feature layer makes shaping work visible: what’s been talked to customers about, what’s been validated, what’s still concept. Without this, features show up at delivery teams half-formed, and delivery teams either build the wrong thing or send it back for refinement.

The user story layer makes delivery state visible: which stories are in flight, which are blocked, which are done. Most teams already have this.

A team running all three layers has a single, connected view from strategic intent down to individual story state. Most teams have layer 3 only — which is why most teams keep hitting the same upstream wall.

Where teams trip up

A few common patterns:

Skipping the feature layer entirely. This is the most common mistake. Product Management does the shaping work but doesn’t visualise it. Stakeholders can’t see what’s in discovery, what’s been validated, what’s still concept. Then features show up at the delivery team without context, and everyone wonders why velocity is unpredictable. Visualising the upstream shaping work is the single highest-leverage move most product organisations can make.

WIP limits at the upstream layers. Most teams put WIP limits on the delivery board (good) but not on the portfolio or feature boards (bad). The result: 40 initiatives “in progress” at the portfolio level, no one knowing which actually has momentum. WIP limits at portfolio (typically 3-5 active initiatives) and feature (typically 6-10 features in shaping) force the prioritization decisions Product Management is supposed to be making.

Treating layers as separate boards instead of connected systems. If portfolio, feature, and story cards are unrelated, you’ve built three siloed Kanban boards, not a connected upstream system. Each card at a higher layer should link to the cards at the layer below it that implement it.

How AI changes this in 2026

A note on what’s different from when the original version of this piece was written in 2013.

Two real shifts:

AI-generated requirements have made the feature-layer shaping work more important, not less. AI can produce a draft requirement in 30 seconds — but draft requirements are not the same as validated, story-mapped, ready-for-delivery requirements. The feature layer is where humans still do the work that AI doesn’t: customer conversations, judgement calls on scope, trade-off decisions.

Portfolio-level reporting is now expected to be near real-time. Executives don’t tolerate quarterly portfolio updates the way they did in 2013. The Kanban approach to portfolio supports this naturally — the board is the report.

What hasn’t changed: the principles. Visualise the work, limit WIP, make policies explicit, manage flow, improve collaboratively. Those work in 2026 the same way they worked in 2013.