Kanban Board

On a team without a board, the state of the work lives in people's heads and in yesterday's messages. Ask and you get an answer; don't ask and nothing surfaces. Chasing status becomes somebody's daily job.

Pagedeck worked that way early on. Mia would ask how far along the notification settings screen was, Theo would say it was nearly there, and "nearly there" sometimes meant the code was written and sometimes meant review had already passed. Same answer, and Mia walked away planning to ship that week while Theo was thinking about the next one.

The counting was the worse problem. Nobody could see that Theo had four things open at once that week. Juggle four items and each one inches forward while none of them finishes, and from the outside all anyone hears is that everything is in progress. What slows work down is usually not how fast people type but how many things they are carrying, and that number was the one thing nobody could see.

Kanban is a way of working that makes flow visible and caps how much runs at once. The board handles the first half of that, moving the state of the work out of people's heads and onto one surface.

What a board fixes is not speed but invisibility. Where each item sits, how many items are stacked in one stage, and which column is quietly eating days — all of it becomes readable without asking anyone.

Three things surface.

1. The current stage of an item. The column a card sits in is that item's workflow status. Instead of "nearly there" you get "it's in the review column."
2. How much is stacked in one stage. Six cards in the development column with four engineers means somebody is holding two items at once. Nobody has to count for that to be obvious.
3. Where the waiting happens. Lead time is the clock from the moment a request arrives until it's done; cycle time starts when someone actually picks it up. The gap between them is the three days a card spends parked in the QA column.

So how you draw the columns decides most of what the board is worth. Rather than copying someone else's columns, put one up at every point where your own team actually waits. Keep only "in development" and "done" and nothing on the board changes when three days vanish in QA.

The board only reveals, though. What changes the flow is the rule you put on top of it. A work in progress (WIP) limit caps how many cards a column can hold, which is what stops the person about to open a fifth item, and a pull system, where whoever frees up takes the next card, is what gives that cap any meaning.

A board isn't the only way to track the state of work.

1. A list. Items in a spreadsheet or a to-do app. Faster for a team of two or three where there's really only one stage. The cost is that finding out where an item stands means asking whoever owns it.
2. A per-cycle list. Scrum teams put the batch of work committed to a two-week cycle into a sprint backlog and watch the remaining amount fall. That fits a team that needs a promise each cycle. The cost is that it never shows which column a card is stuck in inside the cycle.
3. Dated bars. Each item drawn as a horizontal bar with a start and an end date. Nothing beats it when dates are contractual commitments to someone outside. The cost is that on a product team whose priorities shift weekly, redrawing the bars is constant work and the redrawn picture is wrong again within days.

Each option answers a different question, which is why teams end up with more than one of them at the same time. The choice is simple enough. Work that moves one direction through several stages with waiting in between wants a board. Fixed dates want bars. No real stages at all wants a list.

Even with a board, one surface stops being enough at some point. When incident work and new features compete for the same column, the urgent one always wins. That's when a swimlane — a horizontal band across the board — lets you set a separate cap per kind of work.

"There are six cards in the development column right now. Don't open anything new, clear the reviews first."

One stage is overloaded, so push finished work forward instead of starting more.

"There's no card on the board for that."

Unrecorded work doesn't exist to anyone else, so make a card first.

"Let's give QA its own column. Right now it reads as done, but things actually sit there for three days."

The columns have stopped matching the real stages, so the board's structure needs fixing.

Pagedeck runs its daily scrum with the board up. Instead of going person by person through what everyone did yesterday, the team walks the board right to left, starting with the cards closest to done. Pushing nearly finished work over the line helps the team more than opening something new.

When Theo says a card is waiting on an answer from the payments vendor, it gets flagged as a blocker. Cards piling up in the review column are a different animal — that's a bottleneck, a problem with a stage rather than with one card, and it gets fixed by adding reviewers or lowering the cap on the column before it.

The most common expectation is that putting up a board makes work go faster. Adopting Kanban is usually said to mean building a board, so the assumption is a natural one. But the board is a surface that reflects state, and pinning cards to a wall doesn't reduce how many things people hold at once. A team that runs a board with no caps finds itself six months later spending real effort dragging cards around while the time an item takes hasn't moved.

The other one is assuming more columns means more accuracy. Splitting a flow into twelve stages feels closer to reality, but each extra column adds an update somebody forgets, and the board ends up showing a few days ago. Once nobody trusts it, people go back to asking in chat. Put up a column only where waiting actually happens, and merge two columns back together the moment nobody can explain the difference between them.