Kanban Swimlanes: When They Help and When They Hide Work

Kanban swimlanes are horizontal rows across a board, so that every column is split into bands: one row per class of service, per person, per team or per product. The common examples are an expedite lane for urgent work above everything else, a row per person, a row per team on a shared board, and a row per product or client. Swimlanes help when each row really does flow differently and someone needs to see that at a glance. They hide work when the rows multiply, when half of them are empty, or when a row per person turns the board into a list of who is busy. Often a filter or a colour does the same job with less to maintain.

Columns are a separate question. On most boards the word lane means a column, the stage a card is in; see what is a lane. This piece is about the rows that cut across them.

Where swimlanes come from

The Kanban Guide↗ (opens in a new tab) does not prescribe swimlanes, or any layout at all: it says there are no specific guidelines for how a visualisation should look, and that teams are limited only by their imagination in making flow visible. Swimlanes are a convention that grew up around it.

Kanban University’s guide↗ (opens in a new tab) describes lanes as often used for different work types or projects to distribute capacity, and it calls the idea of treating some items differently a class of service, with expedite as the usual example.

Five swimlane schemes, with examples

1. By class of service

Rows for work that is treated differently. The names vary from team to team; a typical set is Standard for most work, Deadline for anything tied to a fixed date, and Maintenance for work that nobody asks for but everybody needs. Each row has its own policy, such as “fixed-date items start at least two weeks before the date”. This is the scheme closest to kanban’s own ideas, because the rows exist to change how work is pulled, not just to sort it.

2. An expedite lane

A single row across the top for work that must jump the queue: the production outage, the payment bug. It only works with strict rules: what qualifies, a limit of one item at a time, and permission to pass the normal work-in-progress limit, which is how Kanban University describes expedite items. Jira builds this in: its documentation on configuring swimlanes↗ (opens in a new tab) says that when you group by queries, it creates an Expedite swimlane for blocker priority and an Everything Else swimlane that catches the rest. For how an expedite slot sits alongside the team’s limit, see WIP limits in kanban.

3. By person

One row per person, so each row shows what one person has in each column. Useful for a manager balancing load across a small team, or when people are genuinely independent. Jira, for example, offers one swimlane per assignee, with unassigned work above or below.

4. By team

One row per team on a shared board, for example Web, Mobile and Platform. It shows where work is piling up across teams, and it is a halfway house for teams that share a release but not a backlog.

5. By product, project or client

One row per product line, project or client, common in agencies and in small companies running several products on one board. GitHub’s documentation for the board layout in GitHub Projects↗ (opens in a new tab) describes this as grouping by a field value to create horizontal sections, and dragging a card between groups changes that field on the item.

When swimlanes help

• The rows flow differently. An expedite item and a standard item really do follow different rules, and a row makes that rule visible.
• Capacity is split on purpose. If the team has agreed that a third of its time goes to maintenance, a row with its own limit shows whether that is happening.
• The board is read by people from several groups. A client or a team can find its row without learning a filter.
• There are few rows. Two or three rows on a screen can be read at a glance; eight cannot.

When swimlanes hide work

• Too many rows push work off the screen. The board no longer fits, people scroll, and the card at the bottom of the lowest row is forgotten.
• Rows by person hide shared work. A row per person rewards everyone for keeping their own row busy and makes pairing or helping someone else look like doing nothing. It also answers “who is busy?” instead of “what is stuck?”.
• An Everything Else row becomes the real board. If most cards land in the catch-all, the other rows are decoration.
• Empty rows look like no work. A row for a product nobody is touching this month still takes space and suggests a gap that is not there.
• Expedite becomes the normal lane. If the expedite row is never empty, it is not expedite; it is a second, unlimited board on top of the first.
• The limit disappears. Column limits are harder to read when a column is spread across five rows, so teams quietly stop counting.

The GOV.UK Service Manual’s guide to a team wall↗ (opens in a new tab) lists what a wall is for: seeing all your work together, showing how it progresses, and spotting what is blocking it. A layout that makes any of those harder is working against the board, however tidy it looks.

Swimlanes best practices

1. Start with none. Add a row only when you can say which decision it will make easier.
2. Keep to three rows or fewer, including any expedite row.
3. Give every row a written policy: what goes in it, and whether it has its own limit.
4. Limit the expedite row to one item and review every use of it.
5. Remove a row that has been empty for a month.
6. Read the board by column first, then by row. The question is still what is stuck, not whose row is full.

Alternatives to swimlanes

Most of what a swimlane shows can be had without splitting the board:

• Filters. A filter by person, product or type shows one slice when you want it and leaves the whole board in view the rest of the time. Nobody has to maintain rows.
• Colours. A card coloured by type, such as bugs in red, shows the mix in every column without dividing it.
• Categories or labels. A short tag for the area of work, such as Billing or Onboarding, can be filtered on and read on the card.
• Priority. An expedite rule written as “the highest priority is pulled first, over the limit if needed” does the job of an expedite row on a small board.
• A second board. If a row never interacts with the others, it may be a separate board, not a row.

On fenbs: no swimlanes, and what to use instead

fenbs has no swimlanes. A board has four fixed lanes, To Do, Next Up, In Progress and Completed, as columns, with no rows across them. What it has instead are the alternatives above:

• Kinds, shown in colour. Every task is a feature, an enhancement or a bug, in indigo, teal and rose red, so the mix in each lane is visible without a row per type.
• Projects and categories. A task can belong to a project, such as a product or client, and a category for the area of work. Both are filters above the board, with No project and Uncategorised options for anything unfiled.
• Filters. Beside search, project and category, you can filter by type, by priority (High is P1 to P2, Medium P3 to P5, Low P6 to P10, or an exact level), by size, by flag, by testing status, and by AI status, such as tasks an AI assistant is working on. While a filter is on, each lane’s count shows how many of its tasks are shown out of the total, so you can tell what the filter left out.
• Priority for expedite. There is no expedite row; a priority of 1 is the most urgent, and a team rule that P1 is pulled first does the same job.

There is no settable assignee on fenbs, so there is no row, or filter, per person. Who moved a task into In Progress is in the History instead, which answers the useful half of the question: who is working on this.