Best Practices for Kanban Swimlanes
The Kanban Swimlanes App is designed to support an operational Kanban board, not a giant backlog. Keeping the total number of items under control is key to making the view readable and useful for day-to-day work.
Performance & focus limits
For best results, keep the total number of items across all connected boards under 500 items (including subitems). The app will show an in-app warning when this limit is reached or exceeded.
Fewer items = less noise = more focus = higher flow.
1. Archive completed work regularly
Completed items should not stay on the operational board forever. Define a clear Definition of Done (DoD) and archive items once they have been in a “Done” state for a given period (for example, 30–60 days). This keeps the board light, reduces noise, and makes current work easier to see.
A simple practice is to use automations in your monday.com boards to automatically archive or move items that have been Done for longer than your agreed threshold. The example below shows how to do this by creating a Date-type column called Archive Date.

2. Separate discovery and ideas from the delivery board
Backlogs of ideas, requests, and early discovery work should not live on the same operational board where the team manages day-to-day delivery. Instead, keep a separate “discovery” or “ideas” board and only move items into the Kanban Swimlane Board once they are ready to be worked on.
To support this, define a clear Definition of Ready (DoR) before an item enters the workflow. For example, items should have an agreed scope, basic sizing, and any key dependencies identified.
- Regularly clean up discovery backlogs by removing items that have been inactive for several months.
- Set a WIP limit on the “Ready” or “Input” part of the workflow to reinforce pull-based practices and prevent overloading the system.
- Only bring new items into the board when there is clear capacity to work on them. In the example image below, you can see how to automate moving items into the projects board from the discovery board once the ready condition is met.

3. Board design patterns for Kanban Swimlanes
Kanban Swimlanes can be used to model different types of boards. Below are some patterns that work well in practice.
3.1 Team or department Kanban view
In this setup, all swimlanes belong to the same team or department. Each swimlane represents a different board or workstream, such as project development, offers, or maintenance.
This view lets the team see how their capacity is split across different kinds of work and makes it easier to spot when project work, sales support, or maintenance is taking too much attention.

Another option is to use swimlanes for different functions such as Engineering, Production, and Assembly, while the columns show stages like This month, Selected, In progress, and Done. This kind of board makes it easy to see how work for a product or order is distributed across departments and where it is currently progressing or getting stuck.

3.2 Program-level Kanban view
At program level, the first board can represent the overall program or portfolio, while the following boards represent individual projects or streams of work. Each project board keeps its own workflow and statuses, but all of them are visible together in a single Kanban view.
A common pattern is to have one swimlane for the program overview (epics or initiatives), followed by swimlanes for active projects, and optionally additional swimlanes for upcoming or on-hold projects.

In this example, the top swimlane shows the program, the middle swimlane shows projects, and the bottom swimlane shows a single project board, with arrows indicating how work items are connected across levels.
You can mix and adapt these patterns as needed, but keeping item counts under control, separating discovery from delivery, and designing boards around real teams and programs will make the Kanban Swimlanes App much more effective.