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.
Industry Reality
- Most boards in the wild violate at least one Kanban principle — WIP limits are set and then routinely ignored when a stakeholder marks something "urgent," which is nearly every week. The board reflects aspirations, not always reality.
- In NZ enterprise teams (banks, government, telcos), Jira boards are frequently configured by someone who left two years ago. Columns accumulate until the board has 12 stages, many of which nobody moves cards through consistently.
- Senior practitioners often maintain a private mental model of actual flow alongside the official board — they know which cards are genuinely in review and which are sitting there because the developer forgot to move them.
- Physical boards in hybrid teams quickly become stale. The team's "board of truth" shifts to whichever tool the most senior engineer prefers, which may or may not be the official Jira project.
- Automated card movement via CI/CD (e.g., Jira tickets auto-transitioning when a branch is merged) is common in mature teams but breaks frequently during pipeline changes and requires ongoing maintenance nobody budgets for.
Context guide
How the right level of Kanban Board effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Government digital services with mixed BAU and project work (e.g. TransitNZ, Benefits NZ) | Essential | Incident and change requests arrive continuously alongside planned releases. Sprint commitments are immediately broken by operational demand. A Kanban board with explicit swimlanes for BAU and project work is the only tool that makes both streams visible without conflict. |
| Financial services QA teams running continuous regression (e.g. Harbour Bank, Pacific Bank) | Essential | Banking platforms deploy in narrow overnight windows. A board with clear "Ready to Deploy" and "Awaiting Sign-off" columns makes the production queue visible to compliance, release managers, and testers simultaneously. WIP limits prevent regression suites from competing with hotfix validation. |
| Small NZ product startups with a single QA engineer across multiple features | High | A sole QA is the most common bottleneck in NZ startups. A Kanban board with a WIP limit on the Test column makes that constraint visible so developers stop pulling new stories before existing ones clear testing. |
| Scrum teams delivering well-scoped features with predictable scope per sprint | Medium | A Scrum task board already provides visibility within the sprint. A Kanban board adds value only if the team wants flow metrics or is running parallel workstreams. Adding it without purpose creates tool overhead. |
| Short-burst test automation projects with a defined start and end date | Low | A simple checklist or sprint backlog is adequate for time-boxed automation uplift work. Setting up a Kanban board with pull policies for a six-week project adds ceremony without meaningful flow data. |
| Cross-timezone teams (NZ + AU + India) where handoffs are the primary bottleneck | Essential | When the NZ team hands off to an India-based automation team each evening, a digital Kanban board with timestamp-visible column entry/exit is the only shared record of where work sat overnight. Without it, handoff failures are invisible until stand-up the next morning at the cost of half a working day. |
Trade-offs
What you gain and what you give up when you adopt Kanban Board.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Bottlenecks become visible immediately — a column filling up signals a system problem, not a person problem. | No built-in cadence for planning or retrospectives. Teams without discipline drift into endless in-progress states with no natural stopping point to reflect. | Your team needs a forcing function for regular planning ceremonies — use Scrum with a sprint board and add flow metrics on top. |
| Handles variable demand well — urgent work can be pulled without breaking a sprint commitment or triggering a re-planning ceremony. | Forecasting delivery dates is harder without sprint boundaries. Stakeholders accustomed to sprint commitments feel less certainty about when things will ship. | Leadership requires predictable release dates per quarter — pair Kanban metrics (throughput, cycle time) with a Monte Carlo forecast rather than switching to Scrum. |
| Flow metrics (cycle time, throughput, CFD) give objective data about team performance that are harder to game than story point velocity. | Requires consistent card hygiene to produce accurate metrics. One month of inconsistent updates renders cycle time data useless for trend analysis. | The team cannot commit to updating the board in real time (e.g. field-based testing roles) — use a lighter daily tally instead. |
| No estimation ceremony required — teams can start flow immediately without sizing every card in advance, reducing overhead for support and ops work. | Absence of estimation can frustrate product owners who need to communicate scope and cost commitments to business stakeholders, especially in NZ government procurement contexts. | Business case or contract requires effort estimates per feature — use lightweight T-shirt sizing on cards without adopting full Planning Poker ceremonies. |
Enterprise reality
How Kanban boards look at 200–300-developer scale in NZ enterprise — banks, government, and telcos.
- Card creation and state transitions are largely automated at this scale. Harbour Bank, for example, integrates Jira with its CI/CD pipeline so that a pull-request merge automatically moves a card from "In Review" to "Ready to Deploy" — no human touches the board during normal flow. The risk: when pipelines break, cards freeze in incorrect states and cycle-time data becomes unreliable for weeks until someone audits the integration.
- Governance and audit requirements add mandatory columns that small teams never need. Under the New Zealand Information Security Manual (NZISM) and PCI DSS, Pacific Bank QA boards carry a "Change Advisory Board Approved" gate before any card can enter "Ready to Deploy." Skipping or bypassing this gate — even for a one-line hotfix — can trigger a compliance incident, a formal post-incident review, and regulator notification obligations under the Reserve Bank's outsourcing and operational resilience framework.
- Tooling must handle volume across programmes, not just teams. Jira Advanced Roadmaps (formerly Portfolio) and Azure DevOps Plans are the standard choices at TeleNZ and government agencies like Benefits NZ — they aggregate Kanban boards from 10–30 squads into a single portfolio view so release managers can see cross-squad dependencies and bottlenecks without opening individual boards. Without this layer, each squad's WIP limit is locally meaningful but programme-level flow is invisible.
- Coordinating board policies across 10-plus squads introduces drift that does not exist in single-team Kanban. Revenue NZ's online services programme discovered that six squads sharing a release train had defined "Done" differently on their boards — some required staging sign-off, others did not. When a Privacy Act 2020 compliance release required proof that all changes had cleared a consistent acceptance gate, the inconsistency forced a two-day manual audit. Standardising column definitions and WIP policies across squads is ongoing governance work, not a one-time setup task.
◆ What I would do
Professional judgement — when to adopt Kanban Board, when to adapt it, and what to watch for.
The bottom line: A Kanban board is a diagnostic instrument, not a decoration. If looking at it does not immediately tell you what is slowing the team down this week, the board design — not the team's behaviour — needs to change first.
Best Practices
- ✓ Keep columns to five or fewer — if you need more than five stages to describe your workflow, split the board into two boards rather than adding more columns.
- ✓ Set WIP limits per column before the board goes live, not after the team is already overwhelmed. Start with the number of team members minus one.
- ✓ Use a dedicated "Blocked" indicator (red sticker, emoji, or Jira flag) rather than a separate blocked column — blocked work should stay visible in its current stage so the stall is obvious.
- ✓ Review and trim the card count at the start of each week. Cards older than two weeks with no movement are either done and forgotten or need to be killed.
- ✓ Distinguish between Scrum-flavoured task boards and genuine Kanban boards. Kanban has explicit policies (pull, WIP limits, flow metrics); a sprint task board does not — using the wrong mental model leads to confusion.
- ✓ Make blocked cards the first item in stand-up, not an afterthought. If the board has three blocked cards, the meeting should be about unblocking them.
- ✓ Integrate the board with your deployment pipeline so "Done" means genuinely shipped, not "merged to main and waiting for someone to push the deploy button."
- ✓ Export cycle time data monthly and share it with the team. Flow metrics are more honest than story point velocity for identifying where the board's design needs improving.
Common Misconceptions
❌ Myth: A Kanban board is just a task list organised into columns.
Reality: A true Kanban board is a system with explicit policies — WIP limits, pull mechanisms, service classes, and flow metrics. Without those policies, you have a colourful to-do list, not Kanban. The board is the visible surface of a discipline, not the discipline itself.
❌ Myth: Kanban boards are for teams that don't want the structure of Scrum.
Reality: Kanban and Scrum solve different problems. Scrum is designed for iterative product development with a defined cadence. Kanban is designed for continuous flow work — operations, support, DevOps pipelines — where demand is unpredictable and there is no natural sprint boundary. Many mature teams run Scrum ceremonies on top of a Kanban board (a hybrid called Scrumban).
❌ Myth: More columns means better visibility into the workflow.
Reality: Every column you add requires the team to actively move cards through it. Boards with eight or more columns typically see cards stagnate in the middle stages because no one owns the transitions. Fewer, well-defined columns with clear exit criteria outperform detailed multi-stage boards in practice.
Senior engineer insight
The teams who get the most from a Kanban board treat it as a mirror, not a manager. They update cards in real time, honour WIP limits even when a stakeholder applies pressure, and use the board data in retrospectives to change the system, not to blame individuals. What separates them from struggling teams is a single habit: blocked cards get acknowledged in the next stand-up, not quietly left in "In Progress" to age gracefully. The specific pattern that works is a weekly 15-minute board health check — count cards older than three days in any column and ask why they haven't moved.
The most common mistake: setting WIP limits once at board creation and never revisiting them. Limits that made sense at team size four become chokepoints at team size seven, and teams stop respecting them rather than adjusting them.
From the field
A Wellington-based support and ops team managing a government digital services platform moved to Kanban after finding their fortnightly sprints couldn't absorb the volume of incoming incidents alongside planned test work. They set up swimlanes — one for BAU test execution, one for production incidents, one for regression — assuming the visual separation alone would fix the chaos. What actually happened: the incident lane consistently blew past its WIP limit because everyone treated incidents as automatic expedites, which meant the regression lane stalled for three weeks running and a release slipped. The fix was adding an explicit policy card pinned to the board: "Incident lane at limit = team pauses to triage before pulling new work." The lesson isn't swimlane design — it's that lanes without written pull policies just let teams argue about prioritisation in a more colourful setting.
Self-Check
Click each question to reveal the answer.
Q: Your team is testing a new claim submission flow for CoverNZ. The feature has unpredictable demand — some weeks bring dozens of edge-case defects, other weeks are quiet. Should you manage testing work on a Scrum sprint board or a Kanban board, and why?
A: A Kanban board is the better fit here. Kanban handles unpredictable, continuous demand well because work is pulled as capacity opens rather than committed to in fixed sprints. An CoverNZ claims flow with variable defect volumes will create uneven sprint loads; Kanban lets the team absorb that variability without the overhead of re-planning mid-sprint. Use WIP limits to prevent testers from picking up too many claims at once.
Q: An Revenue NZ online services team runs two-week sprints in Jira. The Scrum Master wants to add swimlanes for "Standard," "Expedite," and "Blocked" to the sprint board. A colleague says this makes it a Kanban board now. Who is correct?
A: Neither is fully correct. Adding swimlanes to a Scrum board makes it more expressive but does not make it a Kanban board. A genuine Kanban board requires explicit pull policies, WIP limits per column, and flow-based metrics such as cycle time — none of which a standard Jira sprint board enforces. Swimlanes are a display feature, not a methodology. The team is running a Scrum board with visual enhancements, which is fine but different.
Q: What is the key difference between a Kanban board and a Scrum task board, and when does using the wrong mental model cause problems?
A: A Scrum task board tracks sprint commitments against a time-box — cards represent tasks the team agreed to finish by Friday. A Kanban board tracks continuous flow with no sprint boundary — cards enter and exit based on demand and capacity, governed by WIP limits and pull policies. Using a Kanban board with a sprint mindset leads teams to ignore WIP limits and overfill columns ("we have to finish it this sprint"). Using a Scrum task board with a Kanban mindset leads to mid-sprint scope creep and messy sprint reviews. Match the tool to the cadence your team actually works in.
Q: A developer on an TransitNZ road-condition data platform tells you: "We don't need WIP limits — our team is senior and everyone knows what they're working on." What is wrong with this reasoning, and how do you respond?
A: WIP limits are not about trust or seniority — they are a system-level constraint that prevents bottlenecks from building up invisibly. Even skilled teams will naturally start more work than they can finish when demand is high, because starting feels like progress. Without WIP limits, in-progress columns silently bloat, cycle time lengthens, and blocked work gets hidden behind "in progress" status. The response: "WIP limits protect the team from well-intentioned over-commitment. Without them, this is just a colourful task list, not Kanban. Let's set limits at team-size minus one per column and revisit after a sprint." Boards at senior NZ teams such as TransitNZ and Revenue NZ that skip this step consistently report the same symptom: cards that sit in "In Progress" for weeks.
Why teams fail here
- Treating the board as a reporting artefact for management rather than a team thinking tool — cards get moved to match stakeholder expectations rather than actual work state, and the board stops reflecting reality within weeks.
- Adding swimlanes for every work type without pairing them with pull policies — a swimlane without a WIP limit and an explicit priority rule is just visual noise that makes the board harder to read at a glance.
- Allowing verbal overrides of WIP limits under pressure ("just this once, it's urgent") — once the team learns that limits are negotiable, they stop functioning as a system constraint and the board reverts to a push system.
- Designing columns around organisational structure (Dev column, Test column, Ops column) instead of workflow stages — this hides cross-team handoffs and creates invisible queues at the boundaries between swimlanes.
Key takeaway
A Kanban board done well is a real-time agreement about what the team is working on, what it's waiting for, and what it won't start yet — every policy violation is visible the moment you look at the wall.
How this has changed
The field moved. Here is how Kanban Board evolved from its origins to current practice.
Physical kanban cards originate in Toyota's manufacturing system — a visual signal represents a work item moving through production stages. Each station pulls new work only when there is capacity.
David Anderson adapts kanban for software at Corbis — columns representing workflow stages, cards representing work items, WIP limits on each column. The practice is named "Kanban" as a distinct software discipline.
LeanKit, Trello, and later Jira Software provide digital kanban boards. Physical card walls move to the screen. Digital boards enable remote teams, automated card creation, and flow metric calculation.
Kanban spreads beyond software to all knowledge work — HR, marketing, operations teams adopt kanban boards. The visual nature and WIP limit concept prove broadly applicable.
AI-powered kanban tools automatically identify bottlenecks, predict delivery dates from flow metrics, and suggest WIP limit adjustments based on team capacity and historical throughput.