How do you design the columns of a Kanban board so they model the team's real workflow?
answer
- Trace an item that actually shipped
- Activities get named, gaps do not
- Waiting needs a column of its own
- Queue columns carry no owner
- Split where the handoffs are
basics
~20 sTrace an item that actually shipped and write down every state it passed through, including the states where nothing was happening to it. Give the waiting states their own columns; otherwise waiting hides inside the activity columns.
solid answer
~50 sColumns are a **map of how work really gets finished here**, not a template and not the process document. The way to find them is to take an item that genuinely shipped and trace it backwards through every state it was in. Teams reliably name the activities - building, reviewing, testing - because those are the parts people do, and reliably miss the gaps between them, which is where most of the elapsed time usually sits. So split the board into **activity columns**, holding work someone is doing now, and **queue columns**, holding work waiting for the next person or thing. A queue column carries no owner by design, and cards stacking up in it point at whatever is downstream. Choose the resolution the team can keep honest: split where the waiting matters, and merge columns that always hold the same cards.
code
pseudocode · 6 linesBEFORE
To Do | In Progress | Done
AFTER - same work, the queues named
To Do | Building | Ready for bench | On the bench | Ready for review | Reviewing | Done
activity queue activity queue activitygo deeper
Be ready to describe what columns represent: the stages a piece of work passes through in this team. Say plainly that the board should describe what really happens rather than what a process document says should happen.
Explain the difference between an activity column and a queue column and why splitting them is what makes waiting visible. Expect to be asked how you would find the queues hiding inside a single In Progress column.
Demonstrate that you have redesigned a board on evidence rather than opinion. Walk a real item's history, show where the elapsed time actually went, and justify each split by what it lets the team see that they could not see before.
Own the resolution tradeoff and the politics around it. Be ready to argue against columns that mirror reporting lines, to say when a board should be split by service instead of subdivided further, and to explain how you keep it honest as the team grows.
## Model the workflow you have Columns on a Kanban board are a **map of how work actually gets finished here**, drawn at the resolution the team needs in order to see. They are not a template, and they are not a copy of the process document. The way to find them is to take an item that genuinely shipped recently and trace it backwards: every state it passed through, including every state where nothing was being done to it. That last part is the whole trick. Teams reliably name the activities - analysis, building, review, testing, release - because those are the parts people perform. They reliably miss the gaps between the activities, because nobody is doing anything there, and those gaps are usually where most of the elapsed time lives. ## Activity columns and queue columns | | Activity column | Queue column | | --- | --- | --- | | What it holds | Work someone is doing now | Work waiting for the next person or thing | | Owner on the card | Yes, a name | No name, by design | | What growth in it means | People are busy | Something downstream cannot keep up | | Typical name | Building, Reviewing, Testing | Ready for review, Waiting for hardware, Ready to release | A board with only activity columns tells a comfortable story: everything is in progress and everyone is busy. Split the same stretch into `Building | Ready for review | Reviewing` and the story changes, because the cards that are merely waiting now stand in a column of their own where anyone can count them without asking a soul. The split is what makes waiting **visible at all**. Before it, waiting is a property hidden inside a card that somebody has to remember; after it, waiting is a position on the board that every reader can see. ## Finding the queues 1. **List the handoffs.** Every point where work changes hands - to another person, another team, a machine, a customer - is a candidate queue. 2. **Ask where cards wait for a thing rather than a person**: a shared rig, an environment, an approval, a supplier's reply. These are the queues teams most often leave off, because there is nobody obvious to attach them to. 3. **Ask when each card was last actually touched.** A card that sat untouched for days inside an activity column proves that column is hiding a queue. 4. **Name the queue from the puller's point of view.** `Ready for review` says what the next person can pick up; `Waiting on the reviewer` says who to chase, which is a different and worse board. ## A worked example A four-person farm-equipment telematics team ran a three-column board - To Do, In Progress, Done - while working towards a release timed to an annual industry conference. Firmware cards routinely sat in the middle column for about six days, and everyone read that as 'firmware is slow'. When they walked one card's real history, roughly four and a half of those six days had been spent waiting for the team's single hardware bench, which was almost always occupied. They split the middle into `Building | Ready for bench | On the bench | Ready for review | Reviewing`. Nothing about the work itself changed, but the queue in front of the bench was now three or four cards standing in one column, in front of everybody, every day - and the conversation moved from 'firmware is slow' to 'we have one bench'. ## Choosing the resolution More columns are not better. Each column is a state the team has to keep cards in honestly, and a four-person board split into eleven columns is mostly empty rows holding one card each, which reads worse than the coarse version did. - Split a stage when **the waiting inside it matters** and you cannot currently see it. - Split a stage when **different people pull from each half**. - Do not split a stage that always takes an hour and never queues. - Merge two columns that always hold the same cards on the same days. Revisit the board whenever it starts lying: when people are moving cards in a way the columns do not describe, or when a stage everybody talks about does not appear anywhere on it. ## Anti-patterns to recognise - **Columns that mirror the org chart** rather than the work. The board becomes a report about departments and stops helping anyone decide what to pick up. - **A column per person.** Work is then owned by an individual queue instead of flowing through a shared system, and imbalance becomes invisible. - **A Blocked column.** Being blocked is a property of a card, not a stage of the workflow; moving blocked cards out of where they stalled destroys the evidence of where blockages cluster. - **Aspirational columns** for a step the team does not really perform. Cards skip them, and every reader learns that the board is approximate. - **A final column whose meaning nobody wrote down**, where two people mean different things by dropping a card into it.
- When does a waiting state deserve its own column rather than a marker on the card?When cards wait there often enough that the length of the queue is itself information. A column lets you see three cards stacked in front of one shared resource without asking anyone. If the wait is rare, or always minutes long, a marker is cheaper: a column that is nearly always empty adds reading cost and teaches people to skim past it.
- How should the board handle work that comes back from a later stage?Move the card back to the column where the work has to be redone, and make the return visible with a mark or a tally so returns can be counted. Do not invent a Rework column running parallel to the main flow: it hides which stage produced the problem. Frequent returns from one stage usually mean that stage has no written entry rule.
- How many columns is too many for a small team?When most rows are empty and readers have to hunt for the few cards, the resolution has passed what the team can keep honest. A four-person board rarely needs more than six or seven columns. Each one is a state somebody must keep cards in truthfully, so split only where the waiting inside a stage matters, or where different people pull from each half.
It is the difference between a map of the roads and a map that also marks the junctions where traffic stops: the delay is never on the road signs, but that is where the time goes.
saying these in an interview costs you the question
- Copies a three-column template without tracing real work
- Names only the activities and leaves waiting invisible
- Adds a column per person or per department
- Creates a Blocked column instead of marking cards in place
- Keeps aspirational columns that cards routinely skip
- Assumes more columns always make a better board