Kanban Flow: How Work Should Move Across Your Board

Healthy kanban flow means items move from request to done without sitting in a queue nobody owns. You can see it in how fast work finishes, how old the oldest card is, and whether the middle columns keep growing while "Done" stays flat. Fix the stall first. Adding columns, people, or a new tool won't repair a board that already holds too much started work.

What good kanban flow looks like

Kanban flow is the movement of work across a board: what enters, what finishes, and how long each item spends in between. A busy board is something else. A board full of cards in progress can look active and still deliver almost nothing this week.

Three numbers describe the movement.

• Arrival rate: how many items entered the board this week.
• Throughput: how many items reached done this week.
• Age: how long the oldest item in progress has been on the board, plus the typical time from start to done.

If arrival stays above throughput, the board fills up. If age climbs while throughput holds steady, something in the middle is waiting. Cycle time (start to done) and lead time (request to done) are your clocks, but age is what tells you which card is stuck. An average hides that card.

In steady conditions, average work in progress is roughly throughput multiplied by average cycle time. Start twice as many items at once and cycle time tends to double, unless throughput rises with them. The check stops working when the mix of work changes every week, or when "done" means something different on Friday than it did on Monday.

A kanban board is the picture. Flow tells you whether that picture is honest about delivery.

Policies are part of the flow

The columns matter less than the rules behind them. Write down what "in progress" means, who may pull the next card, and what "done" requires before a card can move right. "Review starts only when a second person is free, and it finishes when the notes are answered" is a policy. A column called "Review" is just a label.

Design the kanban work flow before you draw columns

A kanban work flow is the actual sequence work follows, waits included. Map it before you pick columns. If code waits on a design answer, then on review, then on a release window, those waits belong on the board. A three-column board (To Do, Doing, Done) buries them inside "Doing," and age turns into a rumor.

Walk one recent ticket from the first request to production. Write down each handoff and each wait. Give a column to the waits you need to see, and leave the rest as a checklist inside a column. With too many columns, people spend the day moving cards. With too few, a coding problem looks the same as a review queue.

A column set that matches software work

For a product team, this set is usually enough:

1. Ready: specified well enough that someone can pull it. It's not a parking lot for ideas.
2. Build: someone is writing the change.
3. Review: the change is waiting on another person.
4. Ready to ship: accepted, and waiting on a release, a flag, or a deploy window.
5. Done: live, or merged to the line you actually ship from. Say which one.

Ideas belong in a backlog or intake list off this board, or in a column with no work-in-progress pressure. The part of the board that shows flow starts at "Ready."

Operations work often follows a different path: intake, triage, doing, waiting on a customer, done. Use the path you actually have. If you copy another company's columns, you get their waits, and you don't get their results. The kanban board examples from software and ops teams work best as contrasts. Don't paste them in as templates.

Put a wip limit on the columns that wait

A wip limit caps how many items can sit in a column, or on the whole board, at once. When a column hits the cap, people finish or unblock work before they pull anything new. The number on the column header only reminds them of that rule.

Set limits from the constraint, not from headcount. If two people can review at a time, Review doesn't need a limit of ten "so the sprint fits." A limit above what the step can finish turns into decoration. People ignore it, and the board slides back into an unlimited queue.

Some starting points, meant as policy rather than a benchmark:

Column	Starting limit	Why
Ready	5	Enough to pull from, not a second backlog
Build	1 per person who is building	Stops a person holding three half-done changes
Review	2	Makes a queue visible before it becomes the week
Ready to ship	3	Shows a release pile without hiding it in Done

Treat these first numbers as a guess. If Review is always full and Build is always waiting, the limit is pointing at review, so raise Build only after review can take more. One emergency lane with a cap of one is an honest expedite rule. An unlimited "urgent" tag makes every card urgent, and the cap stops meaning anything.

Read cumulative flow before you redraw the board

A cumulative flow diagram stacks how many items have reached each stage on each day. The thickness of a band is how much work sits in that stage. The horizontal gap from started to done is roughly the cycle time of the items finishing at that point.

You want the done line to climb at about the same slope as the arrival line. A band that keeps thickening for days is a queue. If the done line goes flat while the top line keeps rising, the board is taking on work it isn't finishing.

Read it once a week and look for changes in shape. A one-day spike is often noise. A review band that widens for two weeks points to a capacity or batching problem. The chart won't name the blocked card; the age on the card does that. A tool that only stores today's snapshot can't draw the chart later, so keep the daily counts yourself if the tool won't.

A worked example: one board, one week

This is an illustration, not a study. A team of six ships a product. Two people build, one reviews in the mornings, one releases twice a week, and two split their time between build and review. They agree on the limits in the table above. On Monday morning the board holds:

• Ready: 5
• Build: 4
• Review: 6
• Ready to ship: 1
• Done last week: 4 items

Review is over its limit of 2, so nobody pulls new Ready items into Build. Whoever can review clears that column first, and Thursday's release ships what's waiting. By Friday the count is:

• Ready: 4 (one new item was allowed in after a ship)
• Build: 3
• Review: 2
• Ready to ship: 1
• Done this week: 7 items

Throughput went from 4 to 7 because people finished a queue instead of opening more work. They changed the policy and left the codebase alone.

The following Monday, one Build card is nine days old and blocked on a product decision. The team either gets the decision that day or splits the card and sends the undecided part back to Ready. They don't raise the Build limit to make room next to it, and they don't park it in an uncounted "Waiting" column.

Why flow breaks on real teams

Review and release batch up

People save reviews for the afternoon, or ship only on Thursdays, and cards pile up in front of that batch. Review in smaller slices. If a release window is real, show it in Ready to ship so coding doesn't get blamed for the wait.

The board is not the queue

Design questions live in chat, production errors live in another tool, and sales promises live in a spreadsheet. The board ends up measuring a fraction of the load. Either pull those sources onto the board or accept that the chart only shows the work you chose to track. The hidden work still eats the same people's time.

Limits exist and nobody feels them

A limit that's never hit teaches nothing, and neither does a limit you raise in the same standup where it was hit. When a column is full, finish something, unblock something, or swarm the oldest card. Write that response down. If you override it, say so, and get the card back under the limit that same week.

Tool choice matters at the edges. A Trello-style board is enough for a single team that will keep the policy on its own. A Jira kanban board can enforce column limits and a more formal workflow, though it can also turn into a form people avoid. Either way, flow comes from the pull rule, not the board. Atlassian describes the same idea: limit work in progress so the team finishes items before starting new ones (Kanban).

What to change first

Change one thing, then watch throughput, age, and the shape of cumulative flow for two weeks.

1. Name the real waits, and give the worst one a column or a blocked state.
2. Put a limit on that wait that the team will actually feel.
3. Pull from the right only when the next column is under its limit.
4. Each day, look at the oldest card before you look at any new request.
5. Keep "done" stable so this week's throughput compares fairly to last week's.

Leave colors, point systems, and extra swimlanes alone until those five are in place.

If you're choosing software, judge it on stage history, visible limits, and age. A kanban board app that only shows today's columns can't explain last month's queue.

Falrow is one place teams run this loop when requests start as Slack messages, calls, or Sentry errors and need to become tickets with their own stages. Ticket types, triage, and workflow rules keep the columns honest, and the delivery loop includes cumulative flow, cycle time percentiles, and a forecast built from the tickets you already have. You can also run the same practices on a physical board, which works fine, because the practices matter more than the tool.

FAQ

What is kanban flow?

Kanban flow is how work moves from request to done across a board: how much arrives, how much finishes, and how long items wait in each stage. Good flow shows up as steady throughput and low item age, not as a board that looks full. You read it from column queues, item age, and a cumulative flow diagram over time.

How is kanban flow different from a kanban board?

A kanban board is the layout of columns and cards. Flow is whether those cards move under explicit limits and policies. Two teams can share the same board design and get completely different flow if one pulls new work whenever someone is free and the other finishes the oldest card first. The board is where you look; flow is what you're measuring.

What should a WIP limit be set to?

Start from how many items that step can actually finish, not how many you wish were in the sprint. One item per person who is building, plus a small cap on review, is a common starting policy. Lower the cap if cards sit for days. Raise it only when the next step can absorb more, and only after you've watched age for a couple of weeks.

What does a cumulative flow diagram tell you?

It shows how much work has reached each stage over time, so a thickening band means a queue is growing. The slope of the done line is your delivery pace. The chart won't name the blocked card, so pair it with the age of the oldest item. Change one policy at a time so you can tell whether a band thinned because the system actually improved.