What WIP limits should I start with?

Set the WIP limit for "In Progress" equal to your team size minus one. For a team of 5, start with a WIP limit of 4. For "Review," start with 2. For "Ready," start with the number of items your team typically pulls in a week. These are starting points. After 2-3 weeks, look at where cards pile up and adjust. The goal is to create a slight constraint that forces the team to finish before starting.

How is a kanban board different from a scrum board?

A scrum board resets every sprint. You fill it during sprint planning and clear it at the end of the sprint. A [kanban](/glossary/kanban) board is continuous: work flows through it without fixed time boundaries. Scrum boards have a committed scope. Kanban boards have WIP limits instead. Teams that do a lot of unplanned or reactive work (ops, support, platform) often find kanban more natural. Teams shipping large planned features may prefer the structure of sprints. The [Kanban Roadmap](/roadmap-type/kanban-roadmap) explains how to build a roadmap around continuous flow rather than sprint cycles.

How often should we review the board?

Daily, either in a synchronous standup (15 minutes max) or an async Slack check-in. Walk the board from right to left. For each card in Review or In Progress, ask: "Is this moving? Is it blocked? Does it need help?" Once a week, do a replenishment session where the PM moves prioritized items from Backlog to Ready. Monthly, review your WIP limits and column definitions.

Should we use swimlanes?

Only if your board has 15+ active cards and you need visual grouping to stay oriented. Common swimlanes: by work type (Features, Bugs, Tech Debt), by team member, or by initiative. For a small team with 8-12 active cards, swimlanes add visual noise without helping. Try without them first and add them when the board starts feeling crowded.

What tools work best for kanban boards?

Any tool that supports column-based views with WIP limits will work. Linear, Jira, Notion, Trello, and GitHub Projects all support kanban boards. The tool matters less than the discipline. A physical whiteboard with sticky notes and Sharpie WIP limits on each column works better than a perfectly configured Jira board that nobody updates. The [Product Operations Handbook](/product-ops-guide) covers how to choose and configure tools for your team's workflow.

Kanban Board Template

What This Template Is For

A kanban board makes your team's work visible. Every task is a card. Every column is a stage in your workflow. When work moves from left to right across the board, you can see exactly where things stand, where bottlenecks are forming, and what is blocked. The simplicity is the point: anyone on the team should be able to glance at the board and know the current state of work without asking a single question.

This template gives you a ready-to-use board structure with five standard columns, WIP (work-in-progress) limits, and a card format that captures the essentials. It works for product teams, engineering squads, and cross-functional teams managing a continuous flow of work. If you are deciding between kanban and sprint-based workflows, the Scrum vs. Kanban comparison breaks down when each approach fits best. For a deeper look at how kanban boards fit into a continuous delivery roadmap, see the Kanban Roadmap guide.

Kanban works especially well for teams that handle a mix of planned features, unplanned bugs, and reactive support work. Instead of committing to a fixed sprint scope, you pull work as capacity opens up. The WIP limits are what make this work. Without them, a kanban board is just a to-do list with columns.

When to Use This Template

Setting up a new team. Start with this board structure and adjust columns as your workflow becomes clear.
Switching from sprints to continuous flow. Replace sprint backlogs and ceremonies with a kanban board and regular replenishment meetings.
Managing mixed workstreams. When your team handles features, bugs, and support requests simultaneously, kanban lets you prioritize across all three without separate tracking systems.
Visualizing bottlenecks. If work keeps piling up before code review or QA, the board makes the problem visible before it becomes a crisis.
Onboarding new team members. A well-structured board is the fastest way for a new hire to understand what the team is working on and how work flows.
Running an ops or platform team. Teams that respond to incidents, handle infrastructure requests, or manage internal tooling benefit from kanban's pull-based model.

How to Use This Template

Step 1: Define Your Columns

Start with the five standard columns below. These cover most product team workflows. After running for 2-3 weeks, adjust based on where work actually stalls. If every card gets stuck between "In Progress" and "Review," you may need a "Waiting for Deploy" column. If nothing ever sits in "Ready," merge it into "Backlog." The Product Operations Handbook covers how to evolve your board as your process matures.

Step 2: Set WIP Limits

WIP limits cap the number of cards allowed in a column at any time. They are the single most important feature of a kanban board. Without them, work piles up in "In Progress" because starting new things feels productive even when finishing existing work is what the team actually needs. Start with a WIP limit equal to the number of people who work in that stage, then reduce by one. Adjust after two weeks based on throughput data.

Step 3: Create Your Card Template

Each card should capture five things: what the work is, who owns it, how urgent it is, when it is due, and what type of work it is (feature, bug, tech debt, support). Keep cards concise. If you need more detail, link to a spec or ticket. The card is a pointer, not a document.

Step 4: Add Swimlanes (Optional)

Swimlanes are horizontal rows that segment the board by category. Common swimlanes: "Features," "Bugs," "Tech Debt," or by team member. Swimlanes help when your board has 20+ cards and you need visual grouping to stay oriented. For a team with fewer than 15 active cards, swimlanes add clutter without value.

Step 5: Run the Board Daily

Review the board in a daily standup or async check-in. Start from the right side (cards closest to Done) and work left. The goal is to finish work in progress before pulling new work. Flag blocked cards immediately. A card that sits in the same column for three or more days needs attention.

The Template

Board Structure

| Backlog        | Ready (WIP: 3)     | In Progress (WIP: [Team Size]) | Review (WIP: 2)    | Done           |
|----------------|--------------------|---------------------------------|--------------------|----------------|
| Unprioritized  | Prioritized,       | Actively being                  | Awaiting code      | Shipped to     |
| work items     | ready to start     | worked on                       | review, QA, or     | production     |
|                |                    |                                 | design review      |                |

Column Definitions

Column	Purpose	Entry Criteria	Exit Criteria	WIP Limit
Backlog	All potential work items, unprioritized	Any team member can add items	PM moves to Ready during replenishment	No limit
Ready	Prioritized items, ready to be pulled	Requirements clear, dependencies resolved, acceptance criteria defined	Team member pulls into In Progress	[3]
In Progress	Work actively being built	Assigned owner has started work	Code complete, PR submitted	[Team size]
Review	Awaiting code review, QA, or design sign-off	PR submitted or work item ready for review	Approved and merged	[2]
Done	Deployed to production	Review approved, merged, deployed	Archived at end of week or sprint	No limit

Card Template

Each card on the board should follow this format:

Card Title: [Short, descriptive name]

Field	Value
Owner	[Name]
Type	[Feature / Bug / Tech Debt / Support / Spike]
Priority	[P0 Critical / P1 High / P2 Medium / P3 Low]
Due Date	[YYYY-MM-DD or "No deadline"]
Size	[S / M / L / XL]
Blocked?	[No / Yes: reason]
Link	[URL to spec, ticket, or PR]

Type color coding:

Feature: Blue
Bug: Red
Tech Debt: Yellow
Support: Green
Spike: Purple

Swimlane Structure (Optional)

Swimlane	Backlog	Ready	In Progress	Review	Done
Features	[Cards]	[Cards]	[Cards]	[Cards]	[Cards]
Bugs	[Cards]	[Cards]	[Cards]	[Cards]	[Cards]
Tech Debt	[Cards]	[Cards]	[Cards]	[Cards]	[Cards]

Weekly Metrics Tracker

Track these numbers weekly to measure flow health:

Metric	This Week	Last Week	Trend
Cards completed (throughput)	[X]	[Y]	[Up / Down / Stable]
Average cycle time (days)	[X]	[Y]	[Up / Down / Stable]
Cards currently blocked	[X]	[Y]	[Up / Down / Stable]
WIP limit breaches	[X]	[Y]	[Up / Down / Stable]

Filled Example: MobileApp Team (6 People)

Board Snapshot (Week of Feb 17, 2026)

Team: Pulse Mobile App (2 iOS, 2 Android, 1 Designer, 1 QA)

WIP Limits: Ready: 4, In Progress: 5, Review: 3

Backlog (12 items)

Card	Type	Priority	Size
Dark mode support for Android	Feature	P2	L
Add haptic feedback to pull-to-refresh	Feature	P3	S
Migrate analytics SDK to v4	Tech Debt	P2	M
Localization for Spanish and Portuguese	Feature	P2	XL
Investigate crash reports from OnePlus devices	Spike	P2	S
... (7 more items)

Ready (3 of 4 limit)

Card	Type	Priority	Owner	Due
Push notification deep linking	Feature	P1	Priya (iOS)	Feb 28
Fix memory leak in image gallery	Bug	P1	Marcus (Android)	Feb 24
Redesign onboarding flow (screens 1-3)	Feature	P1	Aisha (Design)	Mar 7

In Progress (4 of 5 limit)

Card	Type	Priority	Owner	Started	Blocked?
Biometric login (Face ID / fingerprint)	Feature	P0	Priya (iOS)	Feb 10	No
Offline mode for saved content	Feature	P1	Jun (Android)	Feb 12	Yes: API team has not delivered the sync endpoint
Update payment SDK to resolve App Store rejection	Bug	P0	Marcus (Android)	Feb 14	No
Accessibility audit remediations (batch 1)	Tech Debt	P1	Aisha (Design) + Priya	Feb 13	No

Review (2 of 3 limit)

Card	Type	Reviewer	PR/Link	Waiting Since
Add retry logic for failed uploads	Bug	Jun	PR #847	Feb 16
New user profile screen (iOS)	Feature	QA: Tomas	Build #224	Feb 17

Done (This Week)

Card	Type	Completed
Fix crash on iOS 17.3 when rotating camera view	Bug	Feb 14
Reduce app launch time from 3.2s to 1.8s	Tech Debt	Feb 15
Implement swipe-to-archive on notification list	Feature	Feb 17

Weekly Metrics

Metric	This Week	Last Week	Trend
Cards completed	3	4	Down
Average cycle time	4.2 days	3.8 days	Up (slower)
Cards blocked	1	0	Up (worse)
WIP breaches	0	1	Down (better)

Notes: Offline mode card has been blocked for 5 days. PM to escalate API dependency to platform team lead today. Throughput dipped because the biometric login feature is larger than estimated and consuming most of Priya's time this week.

Key Takeaways

WIP limits are not optional. They are the mechanism that turns a task list into a flow system. Without them, teams start everything and finish nothing.
Start from the right side of the board during standups. Finishing work in progress is always higher priority than starting new work.
Track cycle time and throughput weekly. These two metrics tell you whether your process is healthy. If cycle time is climbing, you have a bottleneck to investigate.
Keep cards small enough to move through the board in 1-5 days. Cards stuck in "In Progress" for more than a week are usually too large and should be split.
Color-code by work type (feature, bug, tech debt) so you can spot imbalances at a glance. If the board is 90% features and 0% tech debt, your codebase is accumulating risk.
Revisit WIP limits every month. As team composition, work mix, or tooling changes, your limits should adjust. The Scrum vs. Kanban comparison explains how to tune these limits based on team capacity and flow metrics.