How to set up a Kanban board for an agentic AI project

In this lesson you'll learn:

• which columns an agentic board needs, and the evidence that moves a card out of each;
• why the swimlanes should be risk bands, and how to set work-in-progress limits;
• the three numbers a programme manager should read off the board every week.

Sound familiar?#

• Every card says "In progress" until it says "Done", and "Done" means someone said so.
• A change to a refund limit sits in the same column, with the same reviewers, as a change to a button label.
• Review is the longest column on the board, and the fix proposed is "review faster".

A board built for software that behaves the same way every time moves cards on status. An agentic board has to move them on evidence.

What is different about an agentic board?#

Three things. Columns end on evidence: a card leaves "harness green" only when every slice it touched is at its bar, because "code complete" says nothing about whether a model's answers are good enough. Lanes are risk bands: what a change touches decides how it is reviewed and gated, so the board makes the band visible. And work-in-progress limits come from review capacity, because when agents write the code, reading it is the scarce resource.

Set it up, step by step#

Step 1 · Create the columns, each with a written exit rule#

Use the nine columns in the diagram. Write each exit rule on the column itself (most tools let you add a description) so nobody has to remember it. The column that matters most is Specified: its exit is the hard gate, and nothing passes it without a signed spec, bar and band.

Step 2 · Make the swimlanes risk bands#

Add a lane per band, R1 to R5, from the authority budget: read-only, reversible writes, hard-to-reverse writes, money, and irreversible changes. A card inherits the band of the most dangerous tool or path it touches, never of its size. The lane then tells everyone, at a glance, how many readers a change needs and whether a named approver must sign.

Step 3 · Put one unknown on every card#

Each card is a bolt, and each bolt carries exactly one unknown, written on the card: does the adapter authenticate?, does ranking hit its bar on codeshare? Add three custom fields: the band, the slice it touches, and the bar for that slice. A card with no unknown should be merged; a card with two should be split.

Step 4 · Set work-in-progress limits from review capacity#

Little's law says the time a card waits equals the work queued divided by the rate it is cleared. Count review in slots, not cards (a change needing two readers takes two) and measure slots cleared per day from the last four weeks. At SkyWays nine changes needed 18 slots against 4.5 a day: a four-day queue. Routing readers by band cut the slots needed to 7 and the queue to 1.6 days, with nobody reading faster. Set the limit on the Building column so that what enters matches what review can clear. Review by risk band

Step 5 · Show blocked decisions, not just blocked work#

Add a marker for a card waiting on a decision rather than on work: a soft gate with a placeholder, an owner and a date. The decision's owner and date go on the card. A card blocked on a decision with no owner is the single most useful thing a programme manager can find on the board.

Step 6 · Read three numbers every week#

Where you'll use it#

• As a programme or delivery manager: the board is your status report, and the three numbers are your weekly update.
• In GitHub Projects, Jira, Linear or any board tool: columns, a band field for the swimlanes, and a slice and bar field on each card are all it needs.
• In the weekly review with the sponsor, alongside the two-number report.

Why it matters#

A status board hides the two things that decide whether agentic delivery is fast: where evidence is missing, and where review is queued. An evidence board shows both. The review queue in particular is invisible on most boards and is usually the longest wait in the whole flow.

Key takeaways#

1. Columns end on evidence, not status, and the Specified column is the hard gate.
2. Swimlanes are risk bands: a card takes the band of the most dangerous thing it touches.
3. WIP limits come from review capacity, counted in slots. Read the queue, the integration rate and the evidence columns weekly.

FAQ#

What columns should an AI project board have?#

Framed, specified, bolt ready, building, harness green, reviewed, in shadow, live and watching, each with a written exit rule that is evidence rather than status. They follow the four phases of the agentic PDLC, from a measured pain to a system being watched for drift.

How do you set WIP limits for AI development?#

From review capacity. Count review in slots (a change needing two readers takes two) and measure how many slots your team actually clears per day. Limit the work entering the build so that it matches what review can clear; otherwise the queue grows, whatever the agents produce.

Should AI agents be on the board?#

The work should be, whoever does it. Each card is a bolt with one unknown, whether a person or a coding agent builds it; the board tracks the evidence the bolt produces, not who typed it.

Can I use Scrum boards for agentic projects?#

Yes, with changes: add the evidence columns after "done" (harness green, reviewed, in shadow, live) because in agentic delivery code complete is roughly the halfway point, and add risk-band swimlanes so review depth is visible.

Apply it in your role#

Across the enterprise. One board template for every AI team gives the portfolio a live view of evidence rather than status, and blocked decisions appear as cards with owners.

The ten-minute workflow. The weekly numbers, straight from an export:

Here is our board export: <CSV>. Compute (1) review queue in days = review slots waiting ÷ slots
cleared per day, (2) the same-day integration rate, and (3) cards in shadow and live, by slice. Flag
any card with more than one unknown, and any money card sharing a lane with read-only work.

Sources and credits#