The Kanban Process: Steps, Flow and Improvement

Updated at

The Answer

The kanban process is the loop you run on top of the work you already do. Visualise every item on a board, cap how many can be in progress at once, let a free slot pull the next item forward, then change one policy at a time based on what the numbers say. Nothing gets installed. You draw the workflow you have today, put limits on the columns where work piles up, and the caps handle most of the rest. Kanban is a method you apply to the way you already work, which is why a kanban process can start on a Monday with nobody’s job title changing.

What Is the Kanban Process?

The kanban process is the way work moves through a kanban system: pulled forward one item at a time, against explicit limits, on a board that shows the state of everything at once. Ask five teams what the phrase covers and you get two answers. Some mean the setup sequence, the steps you follow to get a board running. Others mean the flow itself, what happens to a single card between the request landing and the thing shipping. Both readings are below, in that order.

Kanban the method is a set of ideas. Four change principles, six practices, and a firm preference for evidence over opinion. Your process is whatever your kanban team actually does on a Tuesday. Kanban University’s official guide is blunt about how the two relate, describing kanban as a management approach that should be applied to an existing process. So “kanban process” is shorthand for your process, run the kanban way. People write it both ways round, kanban process and process kanban, and mean the same thing either time.

A kanban framework you adopt would mean redrawing roles and committing to a cadence before anything improved. This asks for neither, which is the practical weight behind the definition above. Call it a kanban management method, a kanban model or a kanban system, and the mechanism underneath every label stays where it is. If you want the plain answer on what kanban is before the process detail, the kanban methodology page has the principles and the six practices, and everything below is what they look like in motion.

What Are the Steps in the Kanban Process?

The kanban process steps run in this order, and the first four are setup you do once.

  1. Map the kanban workflow you actually run. One column per state the work passes through, waiting states included. Do not tidy it up. The mess is the information, and a review queue nobody drew is a review queue nobody can fix.
  2. Put every live item on the board. All of it, as kanban cards, including the half-finished thing someone has been carrying around for a month. This is the uncomfortable step. Every time I have run it the count came out higher than the room expected, and that count is the first useful number the process hands you.
  3. Cap the columns where work collects. Start with the number of people who pull from that column, plus one. Adjust in a fortnight, once you have watched it.
  4. Write the policies on the board. What done means for each column, who pulls next, what happens when something urgent lands at four on a Friday. Unwritten rules get applied inconsistently and cannot be improved, because nobody agrees on what they currently are.
  5. Let people pull. Nobody hands work out. You take the next item when a slot opens in front of you.
  6. Review on a cadence and change one thing. Look at the board and the flow numbers on a schedule, pick a single policy, change it, wait, then judge it.

Steps one to four take an afternoon. Five and six never finish. Most of the confusion sits on the pull step, so it gets the next section to itself.

How Does Work Flow Through a Kanban Process?

Work flows through a kanban process by pull. An item moves forward only when the column ahead of it has room, so the empty space in a column is what starts the next piece of work.

Push fills the Review column past its limit while pull uses a free slot to signal the previous column
Push fills the Review column past its limit while pull uses a free slot to signal the previous column

That backwards signal is the whole mechanism, and it separates a kanban process flow from a to-do list arranged in columns. Push instead, and work starts whenever a person is free. Everyone stays busy, items accumulate in front of whichever stage is slowest, and the queue stays invisible because a busy team looks fine from the outside. A cap on the slow stage stops the flood at its source. The person upstream now has nothing to start, and that feels like idleness for about a week. On our own board I keep Doing at two, and the first fortnight of that was genuinely uncomfortable before the review queue started emptying.

The consequence shows up in how long a single item takes. An item sitting in a queue is not being worked on, and queue time is usually the larger half of the total wait. Cut what is in flight and you cut that wait directly, with nobody working faster or longer. This is why WIP limits are the practice teams skip and then discover they needed.

What the Pull Signal Looks Like on a Digital Board

On a physical board the signal is obvious, because there is nowhere left to put a card. Digital boards need a stand-in. In Kanbanee a capped column carries a badge showing the current count against the limit, and the badge turns red the moment you go over. The limit is soft, so a drag is never blocked. That sounds like a loophole until you watch a team use it. The red badge starts a conversation, and a team that cannot override a limit during an incident stops trusting the board within a month.

Whichever tool you use, the signal has to be visible without anyone asking. If someone has to open a report to find out whether there is room, they will just start anyway.

How Do Feedback Loops Work in the Kanban Process?

The feedback process in kanban is a set of reviews running at different speeds, from seconds to months, each one checking a different thing. Kanban University’s guide makes feedback loops a requirement, because a process with no loop cannot correct itself and quietly drifts back to whatever it was before.

Four loops, ordered by how fast they fire:

  • The WIP limit. The fastest loop on the board, and the one nobody counts as a loop. It fires in seconds, at the moment somebody wants to start something, and a full column answers on the spot.
  • The daily board walk. Once a day. Walk from the done end backwards and ask what would move the oldest card out. The go-around-the-circle version tells you who was busy.
  • Replenishment. Weekly for most teams. The ready queue gets refilled and priorities get set, which is where kanban planning happens without a sprint boundary.
  • The retrospective or flow review. Every two to four weeks. This is the loop that decides what to change, and the only one that can alter the process itself.

Drop all four and the board still works as a visual kanban system. It stops improving, though, and that takes a couple of months to show up anywhere you would notice.

How Do You Improve a Kanban Process?

Kanban process improvement works as a controlled experiment: measure how the process runs now, change exactly one policy, wait for enough finished items to judge it, then keep the change or revert it. The guide calls these safe-to-fail experiments, and the phrase is doing real work. A change you cannot undo is a reorganisation, and it belongs on a different agenda.

Measure the process, change one policy, wait for around twenty finished items, then keep or revert
Measure the process, change one policy, wait for around twenty finished items, then keep or revert

Flow data is noisy. Two good weeks can follow any change at all, including a bad one, which is why the waiting is the part teams get wrong. Wait for roughly twenty finished items before you judge anything. For most teams that is two to four weeks, long enough that the temptation to change a second thing becomes strong. Resist it. Two simultaneous changes produce one ambiguous result, and the flow metrics cannot tell you which of them moved the number. I have yet to see a team judge a change fairly on ten items.

Use the same statistic each time. Cycle time at the 85th percentile is the most useful single one, because it answers how long something usually takes. An average hides the tail, which is the part stakeholders actually complain about.

What to Change First

Candidate changes, roughly in order of how much they tend to return:

  1. Lower a WIP limit by one. Cheap, reversible, and the effect shows up fastest.
  2. Split a column that hides a queue. An In progress column covering both active work and waiting work conceals where the delay lives. Split it into doing and waiting halves and the queue becomes countable.
  3. Add an explicit policy to the column with the most disagreement. Usually review, usually about what counts as done.
  4. Cap the ready queue. A short capped queue between the backlog and the board keeps prioritisation honest, since something has to come out for something to go in.
  5. Change the cadence of a meeting. Last. Meetings are the easiest thing to change, which is why teams start there, and the cycle time usually stays exactly where it was.

Where Kanban Processes Break Down

Kanban processes break down in four places, and the first one accounts for most of the boards I get asked to look at.

No limits. Columns and cards, no caps. Work still gets pushed, the queues still hide, and the team has taken on the extra ceremony without the mechanism that pays for it.

Columns named after people. A column called Designer or With QA stops making sense the week that person is on leave. Name the state the work is in. In design, In review, Waiting on client.

A done column nobody clears. Cards pile up, the board gets slower to read, and the throughput number disappears into the noise. Weekly archiving fixes it and takes two minutes.

Silent policies. Everyone believes there is a rule about urgent work and no two people describe it the same way. Whatever the rule is, it stays outside the process until it is written where the work is. Metrics have the same problem in reverse. A cumulative flow diagram nobody opens is wallpaper, and if a number never changes a policy you can stop collecting it.

Does the Kanban Process Work Outside Software?

Yes, and manufacturing had it first. Taiichi Ohno built kanban at Toyota in the late 1940s to control inventory between production stages, inspired by how supermarkets restocked shelves only as they emptied. A card signalled that a downstream stage had taken parts, which pulled production upstream. Ohno also set out six rules for kanban that read strangely well in an office. Never pass on defective work. Take only what is needed, produce only the amount required, level the flow, fine tune, and stabilise the process.

David Anderson adapted the ideas for knowledge work in the mid 2000s, first at Microsoft and then at Corbis, publishing Kanban: Successful Evolutionary Change for Your Technology Business in 2010. Parts became work items and shop-floor cards became columns. Kanban development practices came out of that translation, and the underlying argument survived it intact.

Kanban project management now runs well beyond kanban software development. Support desks, recruitment pipelines, marketing teams, legal review and hardware manufacturing all use it, because the requirement is not code. You need a repeatable process with a flow of discrete items, and a stage that is slower than the ones around it. Given those two things, a kanban process has something to bite on. A project kanban board for fixed-scope work behaves the same way, since the caps do not care whether the work ever ends.

Kanban in project management manages the flow of work and nothing else. Budgets, scope negotiation, stakeholders and hiring all sit outside it, which is worth saying out loud before somebody expects the benefits of kanban to survive a contract renegotiation.

FAQ

What are the six steps of the kanban process?

Map the workflow you already run, put every live item on the board, cap the columns where work collects, write the policies down, let people pull, and review on a cadence to change one thing at a time. The first four are a one-off setup. After that, five and six just keep running.

What is a kanban process flow diagram?

A kanban process flow diagram is a drawing of the states work passes through, in order, with the limit on each state and the pull direction marked. It is the board before there are cards on it. Sketching one before you build the board is worth an hour, mostly because it forces an argument about what the waiting states really are.

How is the kanban process different from a kanban board?

The board is the artefact and the process is what happens on it. A kanban board can run with no kanban process at all, which is what a board with no limits, no policies and no reviews amounts to. The reverse is rarer, though index cards on a wall count perfectly well.

What are the six rules of kanban?

Ohno wrote six for the Toyota shop floor. Never pass defective parts downstream, take only what is needed, produce only the quantity taken, level the production, use kanban to fine tune, and stabilise and rationalise the process. They predate the software version by around fifty years and describe the same mechanism.

How long does it take before a kanban process shows results?

The board is up in an afternoon and the first honest data arrives after roughly twenty finished items, which is two to four weeks for most teams. Visible improvement follows the first policy change, so treat the opening month as measurement.

Does a kanban process need special software?

No. A wall, sticky notes and a marker run the process fine, and the constraint is physical space, which enforces limits for free. Software earns its place when the team is not in one room, or when you want cycle time and throughput calculated instead of counted by hand.