Table of contents
- From American supermarkets to Toyota's factories
- What the Kanban Guide says
- Why limiting work in progress changes so much
- Four numbers to read off your board
- A first board in one afternoon
- Explicit policies: what "in review" really means
- The pitfalls that kill a board
- Does it actually work?
- To wrap up: the board is just a mirror
- Build your board with FluidOps
- Frequently asked questions
From American supermarkets to Toyota's factories
The story starts in a supermarket aisle. In the 1950s, Toyota engineer Taiichi Ohno noticed that a supermarket only restocks a shelf once a customer has emptied some space, and wondered why a factory couldn't work the same way (Ohno, 1988). The station that uses parts sends a card, the kanban (Japanese for "signboard" or "tag"), back to the previous station: only make what I just used.
Later, David Anderson carried the idea over to software development teams (Anderson, 2010). It then spread well beyond: marketing, HR, small businesses, personal projects. What travels from one world to another isn't the card, it's the principle: you don't start something new until the old work has freed up some room.
What the Kanban Guide says
The Kanban Guide (May 2025) boils the method down to three practices:
- Define and visualize the flow. You draw the stages work really goes through, not those of an ideal diagram.
- Actively manage items. A card that doesn't move is a signal: someone should be able to say why.
- Improve the flow. The board shows where things get stuck; you fix it in small steps.
The Guide adds one requirement: members explicitly control the number of items in progress, from start to finish. A new task starts when there is capacity, not when the mood strikes. That is what's called a pull system.
If you've read Anderson, this version will look leaner. His 2010 book details more practices (making policies explicit, building feedback loops, improving collaboratively). The Guide keeps the essentials and lets each team build the rest.
Why limiting work in progress changes so much
Little's Law links three quantities in a stable system: average work in progress equals average throughput multiplied by average time in the system (Little, 2011). Put differently, time in the system is work in progress divided by throughput.
A worked example. Your team delivers three tasks a week and always has twelve open: each task takes four weeks on average to come out. Cap work in progress at six, and if throughput stays at three a week, the average falls to two weeks. The "if" matters: the calculation assumes a stable throughput. In practice you often keep it, because you juggle fewer topics, but it isn't guaranteed.
The other effect is more human. When everything is "in progress", nothing is really moving, and everyone carries five topics in their head. A cap forces you to finish before you start, which is uncomfortable for the first few days. A more detailed calculation appears in our Kanban vs Scrum comparison.
Four numbers to read off your board
A board doesn't just display, it produces things you can measure. The Kanban Guide keeps four indicators, easy to collect by hand.
| Indicator | What it measures | How to collect it |
|---|---|---|
| Work in progress (WIP) | The number of cards started and not finished | Count the cards between "started" and "done" |
| Throughput | The number of cards finished in a period | Count the cards moved to "done" each week |
| Cycle time | Elapsed time between a card's start and finish | Note the start date and the end date |
| Work item age | Elapsed time since a still-open card started | Spot the oldest card in "in progress" |
The last one is the most useful day to day: it's about living cards, the ones you can still act on. If the oldest card in "in progress" is three times the usual age of your finished cards, that's the one to look at on Monday morning.
A first board in one afternoon
- Write a card for every task genuinely in progress. The rest waits in a "To do" column that you don't look at every day.
- Create three columns: to do, in progress, done. Add "in review" or "blocked" once the need is confirmed.
- Cap "in progress" at two or three cards per person. It's uncomfortable for the first two days, then you get used to it.
- Move cards as you go, and set aside ten minutes a week to look at what stalled.
If you work alone, all of this still works: that's the idea behind personal Kanban (Benson & Barry, 2011). Your limit is often even more useful than a team's, since nobody else stops you from starting an eighth topic.
Explicit policies: what "in review" really means
The difference between a board that helps and a decorative one often comes down to the rules written at the bottom of each column. Two sentences per column are enough: when a card enters, and when it can leave.
- In progress: someone is named, and the next action is clear.
- In review: another person has the card and has promised to respond within two days.
- Blocked: you're waiting for something specific, and you know from whom. A card "blocked" for a week with no named contact is an abandoned card.
- Done: the person receiving the result can use it without asking a question.
These rules need no tool: a paragraph stuck next to the board is enough. Above all they head off endless debates about whether a card is "almost finished".
The pitfalls that kill a board
| Symptom | Likely cause | Remedy |
|---|---|---|
| The board turns into a list | The limit is never enforced | Write the limit at the top of the column and have everyone respect it, the boss included |
| It describes a bygone past | Cards are never moved | Move them at the start of the meeting, or at the end of each task |
| Nobody looks at it | It exists to report to someone else | Build it for the team, and let others consult it |
| An overflowing "blocked" column | Work starts before you're sure you can finish | Check dependencies before moving a card to "in progress" |
| Ten columns for three people | The board describes the org chart, not the work | Go back to three or four columns that mirror the real flow |
Does it actually work?
Honestly, the evidence is thinner than the enthusiasm. A systematic literature review on Kanban in software development (Ahmad et al., 2013) mostly reports benefits for visibility of work, communication and control of work in progress, but relies largely on case studies and few controlled experiments. In other words: the mechanism is sound (Little's Law is proven), and results vary from team to team.
That's a good reason to treat it as a test. Keep the board for three weeks, look at your four numbers, and decide with your own data.
To wrap up: the board is just a mirror
Kanban doesn't make a team faster by magic. It shows what's clogging things up, which is hard to see when everything happens in chat apps and in people's heads. What's left is accepting, now and then, to turn down a new card until the old one is done, which is anything but a technical detail.
Build your board with FluidOps
The demo Kanban board can be used without signing up, and the FluidOps Kanban feature lets you define your columns and track the number of cards per stage. To compare with an iteration-based approach, read about the Scrum method; to keep the rhythm once the board is in place, see day-to-day project tracking.
The free plan is €0 per month, the Individual plan €12 per month or €120 per year, and the Business plan starts at €12 per seat per month billed annually. Details are on the pricing page.
Frequently asked questions
What is the Kanban method?
It's a pull-based way of managing work: you visualize the stages on a board, limit the number of items in progress and improve the flow in small steps. It comes from Toyota's production system.
What does "kanban" mean?
The Japanese word means a signboard or card. At Toyota, a card travelled between two stations to tell the upstream station to make only what the downstream one had just used.
What is a WIP limit?
It's the maximum number of tasks you agree to leave started at the same time. A new task only begins when another is finished, which shortens cycle time at constant throughput (Little's Law).
How many columns should a Kanban board have?
Three are enough to begin: to do, in progress, done. Add "in review" or "blocked" only once the need is confirmed, so the board mirrors the real work rather than an org chart.
What is the difference between Kanban and Scrum?
Scrum organizes work into fixed-length iterations with defined roles and events. Kanban is continuous: it imposes no cycle, but a limit on work in progress and a visible flow.
Sources
- Ahmad, M. O., Markkula, J., & Oivo, M. (2013). Kanban in software development: A systematic literature review. 39th EUROMICRO Conference on Software Engineering and Advanced Applications, 9-16. doi:10.1109/SEAA.2013.28
- Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
- Benson, J., & Barry, T. D. (2011). Personal Kanban: Mapping Work, Navigating Life. Modus Cooperandi Press.
- Coleman, J., Vacanti, D., et al. (2025). The Kanban Guide (May 2025). kanbanguides.org
- Little, J. D. C. (2011). OR Forum: Little's Law as Viewed on Its 50th Anniversary. Operations Research, 59(3), 536-549. doi:10.1287/opre.1110.0940
- Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.