Written by the AgileFever editorial team. Facts checked on November 4, 2026 against the official pages of the organizations named in this post. AgileFever sells training for some of the topics covered here, and we say so wherever it applies. Every board and number in the board sections is an illustrative design we built for this post. None of it is survey data or a client result.
Most kanban board examples show column names and stop there. Copying “To do, Doing, Done” does not tell you how many cards a column should hold, when a card may move, or what to measure. These seven kanban board examples each give columns, a WIP limit with its reasoning, exit policies, card fields, one flow metric and the failure we expect. If you need the basics first, read our Kanban board explainer.
What the usual kanban board examples leave out
Smartsheet’s roundup of 22 board examples (March 18, 2025) lists column names but gives no WIP limit, policy or metric for any board. Asana’s kanban template page names generic To do, In progress and Done stages and describes no WIP limit values. Microsoft’s Azure Boards page is the exception: it caps a stage at two or three items per team member.
The Kanban Guide from Kanban University (version dated May 1, 2025) requires workflow states, a WIP control method, explicit policies and a service level expectation. It prescribes no WIP number. The kanban board examples below fill that gap with numbers you can adjust.
How to choose kanban board columns
Columns are workflow states, not job titles. Draw the board from what happened to the last ten finished items, not from what the process document says. Then apply four tests.
- Add a column only where a card waits or changes hands.
- Give each column an exit policy you can check. “Review done” is vague. “One approval, all comments resolved” is checkable.
- Separate active work from queues. A “Ready for test” column exposes waiting time that “Testing” hides.
- Stop at seven columns. If you need more, you are probably drawing two workflows on one board.
Seven kanban board examples with WIP limits and policies
Each board is a snapshot with every column at or under its limit. Team sizes are assumptions we chose to keep the arithmetic simple.
1. Software delivery board
Illustrative design: four developers, one tester, one product owner.
3/4
4/4
2/3
2/2
1/3
3, no limit
| Design choice | This board |
|---|---|
| WIP limits | Build 4: one per developer. Review 3: reviewers can read three changes without dropping their own work. Test 2: one tester. Ready 4: about a week of work. |
| Exit policies | Ready: acceptance criteria written, fits in about five working days. Build: tests pass, pull request open. Review: one approval, comments resolved. Test: criteria checked. |
| Card fields | Title, owner, class of service, start date, blocked flag, pull request link. |
| Metric | Work item age in Build and Review. It flags a card in trouble before it finishes. |
| Typical failure | Review becomes a parking lot because writing code feels more productive than reading it. Fix: when Review is full, developers review before pulling new work. |
2. Support and bug triage board
Illustrative design with one expedite lane.
2, no limit
3/6
3/4
3/5
2/3
2, no limit
| Design choice | This board |
|---|---|
| WIP limits | Investigating 4: one per person. Fix in progress 3. Waiting on customer 5: a cap forces follow-up. Expedite lane: 1 card across the board. |
| Exit policies | New: severity, product area and reproduction steps set within one working day. Investigating: cause named. Waiting: customer replied. Resolved: customer told, fix linked. |
| Card fields | Severity, product area, customer, opened date, class of service, next action and date. |
| Metric | Cycle time percentile against a service level expectation, such as “85% resolved in three days or less”. The Kanban Guide’s own example uses eight days. |
| Typical failure | “Waiting on customer” hides aging tickets. Fix: past a set number of days, nudge the customer or close the card. |
3. Marketing campaign board
Illustrative design: campaign managers, a designer, a copywriter and one approver.
4, no limit
2/3
4/4
1/2
2/4
2, no limit
| Design choice | This board |
|---|---|
| WIP limits | Creating 4: designer and copywriter carry two each. Review 2: the approver can give feedback on two assets a day. Brief approved 3: older briefs go stale. |
| Exit policies | Brief approved: goal, audience, channel and owner written down. Review: copy, design and tracking links complete. Scheduled: approver signs off once, by a named deadline. |
| Card fields | Campaign, channel, goal, owner, publish date, approver, asset links. |
| Metric | Throughput: assets reaching Scheduled per week. |
| Typical failure | One approver becomes the bottleneck. Fix: a response time in the Review policy and a named backup. |
4. HR recruiting board
Illustrative design. Real boards should hold candidate IDs, not names.
4, no limit
4/6
3/4
2/3
1/2
2, no limit
| Design choice | This board |
|---|---|
| WIP limits | Screen 6: two live screens per recruiter. Interview 4: panel availability is the constraint. Offer 2: each offer needs close follow-up. |
| Exit policies | Interview: role fit checked against written criteria. Decision: all scorecards submitted. Offer: hiring manager and recruiter agree in writing. Closed: candidate informed either way. |
| Card fields | Candidate ID, role, source, stage entry date, next step and date, scorecards submitted. |
| Metric | Work item age in Interview, because candidates leave when they hear nothing. |
| Typical failure | Decisions wait on one late scorecard. Fix: a one-working-day scorecard deadline shown on the card. |
5. Content production board
Illustrative design for a blog or documentation team.
3, no limit
3/3
2/2
1/2
3/4
1, no limit
| Design choice | This board |
|---|---|
| WIP limits | Drafting 3: one per writer. Edit 2: one editor reads two pieces closely. Scheduled 4: about a week of output. |
| Exit policies | Drafting: keyword, audience and outline agreed. Edit: sources linked, facts checked by the writer. Design: one editing pass, headline final. Scheduled: images with alt text, links tested. |
| Card fields | Working title, writer, target date, sources, image status, draft link. |
| Metric | Throughput: posts published per week, read with the age of the oldest card in Edit. |
| Typical failure | Scheduled becomes a stockpile of aging drafts. Fix: keep its limit small and pull nothing in when it is full. |
6. IT operations board with swimlanes
Illustrative design. Limits apply to the column total across all lanes.
5, no limit
4/5
3/3
1/2
3, no limit
| Design choice | This board |
|---|---|
| WIP limits | In progress 5: one per engineer, so an incident replaces a project card and never adds a sixth. Change window 3: what one window carries safely. Verify 2. |
| Exit policies | In progress: owner and rollback plan stated. Change window: approved and scheduled. Verify: executed and logged. Done: monitoring checked. |
| Card fields | Ticket ID, lane, service affected, risk level, window date, rollback plan, blocked flag. |
| Metric | Cycle time by lane. One average would mix three different kinds of work. |
| Typical failure | Incidents eat capacity and projects stall unnoticed. Fix: review each lane’s share of finished cards monthly. |
For longer reading on this kind of board see our post on Kanban for infrastructure operations and support teams.
7. Personal kanban board
Illustrative design.
5, no limit
4/5
2/2
2/3
2, no limit
| Design choice | This board |
|---|---|
| WIP limits | Doing 2: one task plus one unavoidable interruption. This week 5: about what you finish in a normal week. Waiting 3: beyond that you are collecting follow-ups. |
| Exit policies | This week: chosen Monday, nothing added unless something leaves. Done: delivered, not almost. |
| Card fields | Verb-first title, due date if any, start date. |
| Metric | Cards finished per week. After four weeks it tells you how much to plan. |
| Typical failure | Doing grows to eight cards. Fix: finish or move one back before pulling. |
A manufacturing example: two-bin replenishment
Physical kanban works differently: a card or empty bin signals that stock must be made or fetched. The limit is the number of cards or bins in circulation. We cover that in the two-bin kanban explainer.
How to set the first WIP limits on your board
No universal number exists. The Kanban Guide asks teams to control WIP and leaves the value to them. Use either method and treat the result as an experiment.
| Method | How | Example |
|---|---|---|
| By people | One card per person working in that stage. Add 1 or 2 for review or wait columns. | Four developers means Build 4 |
| By target cycle time | Total WIP is about throughput times the cycle time you want (see the next section). | Five items per week and a two-week target means about 10 cards in total |
Start low enough to expose a problem, then change one column at a time so you can see what helped.
What Little’s Law adds to any of these kanban board examples
Little’s Law says average cycle time equals average WIP divided by average throughput. John D. C. Little published the proof in 1961. It holds for a stable system and describes averages, not single items. Our Little’s Law post covers the conditions in detail.
Take a team that finishes 5 items a week. The arithmetic below keeps throughput fixed and changes only how many items are in progress. All numbers are illustrative.
| Items in progress (WIP) | Throughput per week | Average cycle time (WIP / throughput) |
|---|---|---|
| 5 | 5 | 1 week |
| 10 | 5 | 2 weeks |
| 15 | 5 | 3 weeks |
| 20 | 5 | 4 weeks |
| 30 | 5 | 6 weeks |
Throughput held at 5 items a week. Cycle time = WIP / throughput. Numbers are an arithmetic example, not data.
Real throughput does not stay flat. Cutting WIP too far can starve a bottleneck, so tighten limits in small steps. Our Kanban metrics post and cycle time guide explain how to measure the inputs.
What to do with your kanban board on day 1, week 2 and month 2
List the last ten finished items and the states each passed through. Draw those as columns. Put every item you are working on today on the board. Set first limits from the table above and write one exit policy per column.
Find the column that stayed full and the one that stayed empty. Ask why before changing a number. Add missing policies. Record start and finish dates on every card.
Read cycle times from finished cards and write a service level expectation: a time period and a probability. Review limits against it. Add swimlanes only if one kind of work distorts the others.
Class of service is how teams handle urgent items without breaking limits. See our post on class of service and work item type. For card design see what kanban cards hold.
Mistakes teams make with kanban board examples
- Copying one of these kanban board examples without drawing your own workflow first.
- Adding WIP limits that nobody enforces. A limit that is routinely ignored is decoration.
- Leaving out exit policies, so “done” means different things to different people.
- Putting incidents and quarterly goals on one board and averaging them together.
- Skipping start and finish dates, so you cannot compute cycle time later.
- Treating a full column as a people failure instead of a signal about the system.
- Putting personal data such as candidate names on a board the whole company can see.
Learn to design a board with a trainer
AgileFever sells the Team Kanban Practitioner (TKP) course, a one-day live online course whose certification comes from Kanban University. The program page says it covers Kanban principles, practices, events and board design. As listed on November 4, 2026, the price is $550 (regular $600) or Rs 14,000 (regular Rs 14,999). The one-day sessions listed are November 6, November 20, December 4 and December 18, 2026, with two-day formats on other dates. Confirm both on the page first.
Additional discounts are available. Contact us to know more.
You do not need the course to use these kanban board examples. It suits teams that want a trainer to review their own board design.
Questions people ask
How many columns should a kanban board have?
Most teams need four to seven. Add a column only where work waits or changes hands. A solo board can use three. At eight or more, check whether two workflows share one board.
What is a good WIP limit to start with?
Start with about one card per person working in that stage, plus one or two for review or wait columns. Microsoft’s Azure Boards guidance sets a ceiling of two or three per person. Begin lower and adjust one column at a time.
Do I need a WIP limit on every column?
Put limits on every column where work is in progress or waiting. The backlog and the final done column usually have none. Without limits on the middle columns, the board shows work but does not control it.
What is the difference between a kanban board and a Scrum board?
A Scrum board resets each sprint and serves a sprint goal. A kanban board shows continuous flow with WIP limits on states. The tool can be the same. The rules differ: sprints versus pull and flow.
Which metric should I track first?
Track work item age first. It needs only a start date and shows which current card needs help. After a few weeks of finished cards, add cycle time and throughput. The Kanban Guide lists WIP, throughput, work item age and cycle time as its four flow metrics.
Can I use these kanban board examples in Jira or Trello?
Yes. Jira lets you set a minimum and maximum per column. Limits spanning several columns or one swimlane may need an add-on, so check your tool’s current documentation. Our Jira kanban board guide walks through the steps.
