Kanban Board
A visual workflow management tool that uses columns and cards to represent work states, making the flow of work visible to the entire team.
What it is
The Kanban Board is the central visual artifact of the Kanban method. Work items are represented as cards that move through columns representing stages of the workflow. Unlike Scrum boards, Kanban boards represent continuous flow rather than time-boxed sprints. The board should reflect reality, not an idealised process. Good boards use swimlanes to separate work types and make patterns visible at a glance.
Origin: Kanban boards trace their lineage to Toyota's production system in the 1940s. The word kanban is Japanese for "visual signal" or "card."
A well-designed board makes bottlenecks obvious, shows where work is piling up, and helps the team self-organise around flow improvement. It is a tool for the team, not a management dashboard.
When to use it
Kanban boards are especially effective for:
- Ongoing operations — maintenance, BAU, and support work without fixed end dates
- Support teams — help desks, NOCs, and service desks managing incident queues
- DevOps and continuous delivery — deployment pipelines and release flows
- Complementary tool within Scrum — tracking sprint progress while preserving flow thinking
Key benefit: Instant visibility into workload, early identification of blockages, and a shared understanding of team capacity without requiring estimation ceremonies.
Key concepts
Columns
Columns represent stages of the workflow. Common examples include To Do, In Progress, In Review, and Done. Keep the number of columns small enough to remain readable but large enough to show where work stalls. Each column should map to an actual state change, not an organisational handoff.
| Column | Purpose | Exit criteria |
|---|---|---|
| Backlog | Prioritised queue of upcoming work | Team pulls when capacity opens |
| In Progress | Active work | Implementation complete |
| In Review | Code review, testing, or peer review | Review passed, feedback addressed |
| Done | Deployed or accepted by stakeholders | No further action required |
Cards
Cards represent individual work items. A good card includes a concise title, a unique identifier, the assignee, and visual signals for priority, type, or blockers. Avoid cramming cards with metadata — if the card needs more than a glance, the board loses its visual power.
Swimlanes
Swimlanes are horizontal rows that separate work by type, priority, or service class. Common swimlanes include Standard, Expedite, and Fixed Date. They help the team agree on which work gets pulled first when capacity frees up.
Pull vs Push
In a healthy Kanban system, work is pulled by the next stage when capacity becomes available. Pushing work onto overloaded stages creates queues and hides bottlenecks. The pull mechanism is what makes WIP limits effective.
Digital vs Physical boards
Physical boards (whiteboards with magnets or sticky notes) excel for co-located teams: they are always visible, encourage movement, and feel tactile. Digital boards (Jira, Azure DevOps, Trello, Linear) support distributed teams, automated reporting, and integration with CI/CD pipelines. Many teams run both.
Common pitfalls
- Too many columns — boards with ten or more stages become hard to read and obscure flow. Merge adjacent stages instead.
- Not updating in real time — a board that lags behind reality is worse than no board at all. Make card movement part of the team's working agreements.
- Hiding blocked work — blocked cards should stay visible, often in a dedicated "Blocked" column or with a visual marker. Hiding them removes the pressure to unblock.
- Using without WIP limits — a Kanban board without WIP limits is just a task list with extra colours. Set limits and respect them.
- Treating as a management reporting tool — when boards become status reports for external stakeholders, teams game the system and visibility is lost.
Smell test: If your stand-up is spent updating the board rather than discussing blockers and flow, your board has become an administrative burden rather than a thinking tool.
NZ context
Digital Kanban tools are standard in New Zealand tech teams. Jira and Azure DevOps dominate in enterprise and mid-market organisations, while Trello, Linear, and GitHub Projects are common in startups and smaller agencies. Many teams integrate boards directly into Slack or Microsoft Teams for notifications.
Physical boards remain popular for co-located teams, especially in Wellington and Christchurch where office culture still supports in-person collaboration. Hybrid teams often run a digital board of record with a simplified physical mirror for the days everyone is in the office.
Local note: NZ teams often work across multiple time zones (AU, US West Coast, APAC). A digital board with clear handoff timestamps is essential when flow crosses timezone boundaries.
Career level guidance
Grad
Learn to read the board before stand-up. Move your own cards promptly when state changes. Ask what WIP limits mean and why they matter. Do not add personal tasks that the team did not agree to.
Junior
Keep your cards up to date without being reminded. Surface blockers on the board as soon as they appear, not at the end of the day. Start suggesting small column or swimlane changes when you notice repeated confusion.
Senior
Shape board design to match actual team workflow, not a textbook template. Coach others on pull vs push. Use board data to start conversations about cycle time and throughput. Integrate the board with CI/CD status so cards update automatically.
Test Lead
Design board policies that make quality gates visible without adding bureaucracy. Use swimlanes to separate test environment work from production support. Review board analytics monthly to spot systemic delays and feed insights into retrospectives.