Swimlane

Put every kind of work on one board and the urgent work always rises to the top. Urgent work rising is the correct call, and when that call repeats daily, work that isn't urgent never gets started. Nobody decided that, and the result happens anyway, one correct call at a time.

Pagedeck's development board worked that way. One kanban board — the board that lays work into columns by state to show the flow — held four kinds at once: new features, bug fixes, items an enterprise customer had asked for as a contract condition, and internal improvements the team had set for itself. Theo pinned urgent bugs to the top every time, and he was right to. Three internal improvement cards had sat in the same position for three months.

What Mia asked when she looked at the board wasn't about priority. It was whether four kinds should flow under one set of rules. A bug has to finish the week it arrives, an enterprise request has a promised date, and an internal improvement has no date but also must not stall completely. Line up work with different expectations in one row and the rules of the most urgent kind cover everything else. A swimlane splits the board horizontally and gives each kind its own row and its own rules.

The columns stay as they are and the board gets divided across. Columns mean state; rows mean the kind of work. Five things get decided.

1. Pick exactly one basis for dividing. By kind of work, by urgency, or by who requested it. Mix two bases and rows multiply until the board is unreadable — four kinds and three urgency levels makes twelve rows.
2. Keep it to three or four rows. Past six, each row holds one or two cards, and at that point dividing has stopped showing you a flow. Merge the similar kinds until each row carries enough cards to show a pattern.
3. Set rules per row. This is where the device earns its keep. Put a separate work in progress limit — the ceiling on items running at once — on each row, and write an expected duration per row as well. The bug row at a limit of two and within three days; the feature row at three and within two weeks. Those two numbers are what make the rows behave differently.
4. Keep one expedite row, for items that stop everything else, like the service being down. Set its limit to one, and attach a rule that no other row starts new work while a card sits there. It needs an abuse limit too: without a count like two per month, everything arrives as expedite within three months, and the row stops meaning anything.
5. Set a floor where there's no date. A row like internal improvement needs a minimum rather than a maximum. Declare that one card must always be in progress there and the three-months-frozen state stops happening, because the empty row becomes a visible violation.

One more thing becomes visible after dividing: which kind is starving. Mixed together, internal improvement falling behind shows up only as card position; split into rows, a row that doesn't move is obvious at a glance to anyone walking past.

The most common home is a development team's board, where the four kinds above become four rows. Set up that way, the question asked in a retrospective changes. Instead of what fell behind, you ask which row fell behind, and the answer is usually a rule rather than an effort problem, which is a conversation a team can actually act on.

Three other places.

1. Measuring flow time — measure cycle time, the span from starting actual work to finishing it, per row. One overall average tells you nothing in a team where bugs take two days and features take three weeks.
2. Finding bottlenecks — when only one row is stuck in the same column, the cause belongs to that kind. A bottleneck is the slowest segment, the one that sets the pace of the whole flow, and rows let you separate a bottleneck in a stage from one in a kind of work.
3. Support queues — split incoming tickets into outage reports, how-to questions, and feature requests, each with a row. Expected response times differ, so one row forces you to treat everything by the most urgent standard, which is expensive for the questions that could have waited.

Some situations don't suit it. A team where five cards move in a day doesn't have the volume to divide; three rows of one card each show less than one row of three. Neither does a board where lines got drawn without rules attached to them. In that case nothing changes except that the board got busier.

"Let's not keep bugs and features in the same row. The expected durations are different."

Give each kind its own rules.

"Three cards in the expedite row. We're already past this month's limit."

The exception row is being abused.

"The internal improvement row has been empty for three months."

Splitting rows exposed the kind that was starving.

Mia divided Pagedeck's board into four rows: expedite, bugs, features, internal improvement. Expedite got a limit of one and two per month, bugs a limit of two and three days, features a limit of three, and internal improvement a floor requiring one card always in progress.

Two months later, two things had changed. The three frozen internal improvement cards had all finished, and items arriving as expedite had dropped from five a month to two. The second happened because of visibility rather than the rule: requesters saw this month's expedite was full and filed into the bug row themselves.

The most common reading is that rows are a priority order, since the upper row looks more urgent. But a row denotes a kind, and order is set separately within a row. Read as priority, cards in lower rows get treated as though they wait for upper rows to empty, which leaves you exactly where you were before dividing. The expedite row is the one exception: it genuinely holds the authority to stop other rows, which is why it carries both a limit and a monthly cap.

The other common reading is that dividing alone makes management easier, because the board looks tidier. But what this device does isn't partition the board — it makes it possible to attach different rules per partition. Draw lines without setting limits, expected durations, or floors and the cards sit in four clumps flowing exactly as before. It's why teams that drew the rows and never set the rules tend to remove the rows again two months later.