What are kanban boards and why do they work?
A kanban board is a visual system for tracking work as it moves through stages from start to completion. The board is divided into columns, each representing a workflow stage. Individual tasks live on cards that move from left to right as work progresses. The entire state of a project is visible at a glance - no status meetings required, no spreadsheets to update, no guessing about what anyone is working on.
The concept originated in Toyota's manufacturing system in the 1940s, where physical cards tracked parts through an assembly line. Software teams adopted the model because it maps naturally to how code moves through a development pipeline: someone writes it, someone reviews it, someone tests it, and it ships. The board makes that flow explicit and shared.
Kanban boards work because they replace process memory with visual state. Instead of relying on people to remember what stage a task is in, the board shows it. Instead of relying on managers to track who is overloaded, the board shows it. Instead of relying on meetings to surface blocked work, the board shows it. Every piece of information that teams typically chase through Slack messages and email threads is right there on the board, updated in real time.
Column anatomy: the stages of your workflow
The columns on a kanban board represent the stages work passes through. The right column structure depends on your team and process, but the standard five-column layout works for most software teams out of the box.
Backlog
The backlog is a holding area for work that has been captured but not yet committed to. Feature ideas, reported bugs, technical debt notes, and improvement suggestions all live here. The backlog is intentionally unordered or loosely ordered - it is not a to-do list. It is a pool of potential work that gets pulled into active columns during planning.
A healthy backlog grows and shrinks. If it only grows, you are capturing faster than you are deciding. Periodic grooming - reviewing the backlog to remove stale items and re-prioritize - keeps it useful. In Flux, you can use labels to tag backlog cards by type or priority so grooming sessions move faster.
To Do
To Do holds work that the team has committed to completing in the current cycle. Moving a card from Backlog to To Do is a deliberate act - it means someone has decided this task is worth doing now. The column should be small enough that the team can realistically finish everything in it before the next planning session.
In Progress
In Progress is the active work column. A card here means someone is actively working on it right now. This is the most important column to apply a WIP limit to, because it directly controls how much parallel work the team is doing. Without a limit, this column tends to fill up as people start tasks faster than they finish them, which leads to context switching and longer cycle times.
Review
Review covers quality gates - code review, QA testing, design review, stakeholder sign-off, or any checkpoint before work is considered done. Cards in Review are finished from the author's perspective but need verification from someone else. If cards pile up here, it usually means the team needs to allocate more time to reviewing each other's work rather than starting new tasks.
Done
Done is the terminal column. A card here means the work is complete, reviewed, and shipped (or ready to ship). In Flux, you can mark a column as the Done column, which enables automatic tracking of completion dates and throughput metrics. Cards in Done are not deleted - they form a record of what the team has accomplished.
When to add more columns
Add a column when work consistently stalls at a transition that the existing columns do not represent. Common additions include a Design column before To Do (for teams where design precedes development), a QA column between Review and Done (for teams with dedicated testers), or a Blocked column for work that is waiting on an external dependency. Some teams also use swimlanes - horizontal rows that group cards by team, priority, or work type - to add a second organizational dimension without adding more columns. Avoid adding columns for every micro-stage - if a card spends less than a few hours in a column, it probably does not need its own column.
Card structure: what goes on a task card
A card is the atomic unit of work on a kanban board. It represents a single task, bug, feature, or piece of work that one person (or a small group) can complete. A well-structured card contains everything someone needs to start working without asking questions.
Title
The title should describe the outcome, not the activity. "Fix login timeout error on mobile" is better than "Look into auth issue." Titles appear on the board in a compact view, so they need to communicate the task at a glance. In Flux, each card also gets a human-readable ID (like PL-42) for easy reference in conversations and commit messages.
Description
The description provides context. What is the problem? What does done look like? Are there constraints or decisions that have already been made? A good description saves the assignee from needing to track down background information. For bugs, include reproduction steps. For features, include the user story or acceptance criteria.
Labels
Labels categorize cards along dimensions that columns do not cover. Common label schemes include priority (urgent, high, normal, low), type (bug, feature, chore, documentation), and team (frontend, backend, infrastructure). Labels are board-level in Flux - create them once and toggle them on any card. Filter the board by label to focus on a specific priority or type.
Checklists
For tasks with multiple steps, checklists break the work into concrete sub-items. The card shows a progress indicator on the board view (for example, 3/5 done), so you can see at a glance how far along a task is without opening the card. Checklists are especially useful for deployment procedures, onboarding steps, and multi-part bug fixes.
Assignees
Every card in an active column should have an owner. Assigning a card makes it clear who is responsible for moving it forward. In Flux, assignees are visible on the board as avatar icons, so you can quickly scan who is working on what. Cards can have multiple assignees for pair work or shared responsibility.
Due dates
Due dates add time awareness to the board. Not every card needs one - backlog items and chores often do not - but cards with external deadlines or dependencies should always have a due date. Flux shows overdue cards with a visual indicator so nothing slips past unnoticed.
WIP limits: the most underused kanban practice
WIP limits cap the number of cards allowed in a column at the same time. When a column hits its limit, no new cards can enter until something moves out. This is the single most impactful practice on a kanban board, and it is the one most teams skip.
Without WIP limits, the In Progress column becomes a graveyard of half-started tasks. People start work because it feels productive, but finishing work is what actually delivers value. WIP limits enforce a finish-first culture by making it physically impossible to start new work when the pipeline is full.
How to set WIP limits
Start with a WIP limit equal to the number of people on the team for the In Progress column. If you have four engineers, set the limit to four. Run with that for two weeks and observe what happens. If cards still pile up, lower the limit. If the column is frequently empty and people are idle, raise it. The goal is a steady flow where cards move through columns at a predictable pace.
Apply WIP limits to the Review column as well. A common pattern is to set Review's limit to half the In Progress limit, which encourages the team to review each other's work before starting new tasks. This keeps the feedback loop tight and prevents a review bottleneck from forming.
Drag-and-drop workflow and real-time sync
The physical act of dragging a card from one column to another is what makes kanban boards feel immediate. It is a deliberate action - you are declaring that this task has moved to the next stage. In Flux, drag-and-drop is powered by a real-time sync engine that pushes changes to every team member's screen instantly.
When you move a card, every other person viewing the board sees it move within seconds. There is no refresh button, no polling delay, and no stale state. The activity log records every move with a timestamp and the user who made it, so the board is not just a snapshot of current state - it is a full history of how work flowed.
Reordering cards within a column is just as important as moving them between columns. Card order within To Do communicates priority - the card at the top is the next one to pick up. In Flux, you can drag cards to reorder them, and the order is preserved and synced across all viewers.
What happens during a drag
When you start dragging a card, Flux shows a ghost placeholder at the drop position so you can see exactly where the card will land. The card's original position stays visible until you drop it, so you always know where it came from. If another team member is moving cards at the same time, optimistic concurrency control ensures that both moves are applied without conflicts. In the rare case of a version mismatch, the board automatically refreshes to show the authoritative state.
How real-time sync keeps boards current
A board that shows stale data is worse than no board at all, because people make decisions based on what they see. Flux uses server-sent events (SSE) to push every mutation - card created, card moved, label changed, comment added - to every connected client in real time. There is no polling interval. Changes propagate within seconds of being made.
When a team member's browser tab is hidden (they switched to another tab or minimized the window), the SSE connection closes to save server resources. When they return, the connection reopens and the board cache is refreshed to catch up on any changes made while they were away. This means the board is always current when you are looking at it, without wasting bandwidth when you are not.
For teams building automation on top of their boards, the MCP server and REST API trigger the same real-time sync. A card created by a CI/CD pipeline or an AI agent appears on the board instantly, just like one created by a human. This makes automated workflows feel native rather than bolted on.
Setting up your first kanban board
Starting a kanban board is a five-minute process. Create the board, keep the default five columns (or rename them to match your vocabulary), and start capturing tasks as cards. Do not over-engineer the setup - the board will evolve as your team's workflow becomes clearer.
- Step 1: Create a board in Flux and name it after the project or team (for example, "Backend Q3" or "Mobile App").
- Step 2: Keep or rename the default columns: Backlog, To Do, In Progress, Review, Done.
- Step 3: Create three to five labels for priority or type. Start simple - you can always add more later.
- Step 4: Add your team members so they can see the board and be assigned to cards.
- Step 5: Move your existing tasks onto the board. Do not try to capture everything at once. Start with what the team is working on right now, then add backlog items over the next few days.
The most important thing is to start using the board immediately. Move cards every day. A board that is not updated becomes a museum exhibit - interesting to look at but useless for making decisions. The daily habit of dragging cards is what makes kanban work. To skip the blank-board problem entirely, start from a kanban board template with columns and labels pre-configured.
For standardized setups you can reuse across projects, see the guide on task templates. For a deeper look at how kanban boards connect to broader task management workflows, start with the pillar guide.