12 Kanban Board Examples From Real Software and Ops Teams

A useful kanban board example has a short set of columns, a work-in-progress limit on the active ones, and a written rule for what "done" means on each card. The twelve layouts below are boards that software and operations teams run every day: feature delivery, bugs, incidents, support, onboarding, and more. Copy the closest one, then change one column at a time until the board matches how work really leaves your team.

A kanban board example you can copy this week

This sample kanban board is for a product team of six to ten people working on one web app. A smaller team can drop a column. If pull requests already are the review, skip a second review column.

Column	WIP limit	What belongs here	Exit rule
Inbox	none	New requests, bugs, ideas	Accepted, declined, or a question sent back
Ready	8	Accepted work with a clear outcome	Someone has pulled it
Building	3	Code in progress	Pull request opened
Review	3	Waiting on review	Approved, or returned to Building with a reason
Verify	2	Merged, waiting on a real check	The outcome on the card is true in the product
Done	none	Shipped this cycle	Stays until cycle review, then archives

Take one card through it. "Customers can export last quarter's invoices as CSV" comes into Inbox from support. Triage accepts it, because finance has asked twice and the change is one endpoint plus a button. It sits in Ready until someone pulls it. While three cards are open in Building, a fourth can't enter. Verify means the CSV downloads in staging with the right columns. Done means a customer could use it today.

A Monday that follows this kanban board example looks ordinary. Building already holds the CSV export, a retry on failed annual renewals, and a fix for the wrong tax line on EU invoices. Review holds two pull requests, and the older one has waited since Thursday, so the first person who frees up reviews it. After approval, the tax-line card moves to Verify. The person who opened it compares a staging invoice with last month's PDF and moves the card to Done. Only then does someone pull the next card from Ready.

The usual slip is splitting the CSV card mid-week. The button ships, the endpoint waits in Ready, and Done shows a feature customers still cannot use. If the endpoint is really a separate project, send the card back to Inbox and write a smaller outcome, such as "export the last 50 invoices as CSV, without filters."

The board has two policies:

1. A card in Building or Review names a person. "The team" is not a name.
2. A card blocked for more than one working day shows a reason and who can remove the block. It does not move backward to hide the wait.

That's the whole system: columns, limits, exit rules, and somewhere to show blocked work. The other layouts below use the same shape for different kinds of work.

If you want the basics of columns, cards, and limits before picking a layout, read What Is a Kanban Board? A Practical Guide for Software Teams.

What every sample kanban board needs

Teams often copy columns from a screenshot and then wonder why the board falls apart. Whether a sample kanban board stays honest past the second week depends on five things.

• A pull rule. People take the next card from Ready. Nobody hands out work in a Monday meeting unless it really needs a specific person.
• WIP limits on active columns. Inbox and Done can be unlimited, but Building, Review, and any waiting column need a number the team can see. If you raise the limit every time you hit it, you don't have a limit.
• One outcome per card. "Improve billing" is a theme. "Failed annual renewals retry once before we email the customer" is a card.
• An exit rule for each column. If two people disagree on when a card can move, the column name is decoration.
• A blocked signal on the card. Blocked should not be a column where you park things so the WIP limit looks fine.

Set the first WIP number to the count of people who can do that step on a normal day. If those same people also review, subtract one from Building. Three engineers who review each other's work might cap Building at 2 and Review at 2. Keep that guess for two weeks, then change one column. If you raise every limit on Friday because the board looks stuck, the numbers were optional all along.

Write the card before it enters Ready: a title, a type, and one sentence a teammate can check. "Retry failed annual renewals once, then email the customer" can be verified. "Make billing more reliable" cannot.

A type field (bug, feature, chore, incident) lets one team filter mixed work without splitting it across three tools on day one. Keep the board to work this team finishes. A company-wide board looks full but tells you nothing about wait time.

12 kanban examples from software and ops teams

These kanban examples are typical layouts. The names and limits are specific so you have something to argue with. Use whatever words your team already uses.

1. Feature delivery

Columns: Inbox, Ready, Building, Review, Verify, Done. Cap Building at one card per person who is coding, Review at the number of people who can approve today, and Verify at 2. This layout usually goes wrong with a Review column full of pull requests older than a week. When that happens, lower the Building limit before you hire. The other miss is Verify with no named checker: the pull request merged on Tuesday, and the customer finds the gap on Friday. Name the person and the click, such as "download last quarter in staging and confirm invoice number, date, and total."

2. Bug triage and fix

Columns: New, Confirmed, Ready, Fixing, Checking, Done. Cap Fixing and Checking at 2. Once a week, close or send back anything in New that has no reproduction steps. Confirmed means someone on the team has seen the bug. Checking means someone retested the original report; a green test suite alone doesn't count. If bugs are rare, a bug type on the feature board is enough.

A card without steps should not reach Confirmed. "Export is broken" goes back to the reporter with three questions: which account, which quarter, and what they saw instead of a file. A card that says "reproduced on the staging EU account, Q1 export returns an empty file" can enter Ready.

3. Incident response

Columns: Detected, Mitigating, Watching, Reviewing, Closed. Cap Mitigating at one card per incident commander, and leave Detected uncapped. This board is for live customer impact. A card leaves Watching only after a quiet period you set in advance, such as 30 minutes with no new errors on that path. Reviewing is a short note on what broke, what changed, and what you won't fix this week.

Say a card titled "Checkout returns 500 after the payments deploy" sits in Mitigating with the commander named. Watching starts when that path is back to its earlier error level, and the quiet period is already written on the card. If you close at the rollback and skip Watching, the next 500s have no card to update.

4. Platform and reliability

Columns: Signals, Ready, In progress, Validating, Done. If two people share one queue, cap In progress at 2 for the pair. Signals holds only the alerts and toil you will act on. Validating means the chart moved; a merged pull request isn't enough. A signal ignored for a month is not a card yet. Either schedule it with an outcome such as "page only when checkout error rate stays above the pre-deploy line for five minutes," or delete it from Signals.

5. QA and release checks

Columns: Waiting for build, Testing, Blocked on fix, Ready to ship, Released. Cap Testing at the number of people testing today. Cards here are release candidates, not stories. If you add a second test card for each story, you end up with two sources of truth. When a candidate fails, move it to Blocked on fix and name the person who owns the fix. Leave the story on the feature board and link the two cards.

6. Product discovery

Columns: Problem, Shaping, Ready to build, Handed off. Cap Shaping at 2. The board ends when engineering pulls the work. A card leaves Shaping with an outcome, a size the team believes, and a note on what you won't build.

"Customers want better exports" is a problem, not a shaped card. Shaping ends with something like "CSV of last quarter's invoices: invoice number, date, total; no filters in this version." The note on what you won't build keeps Ready to build from turning into a second Inbox. If that note is missing, the card stays in Shaping.

7. Support escalation

Columns: Escalated, Needs info, Accepted, With engineering, Resolved, Replied. Cap Accepted at 5. Support owns the customer columns, and engineering owns Accepted and With engineering. Anything in Needs info for more than three days goes back with a specific question.

Write the question on the card before it enters Needs info. "Which invoice number, and did the download start?" is a question. "Waiting on customer" is a label that hides the wait. When engineering finishes, Resolved means the fix is in the product, and Replied means the customer got the answer in the same thread they wrote in. Skip Replied and the ticket is closed inside the company but still open for the customer.

8. Design alongside engineering

Columns: Brief, Exploring, Ready for build, In build, Shipped. Cap Exploring at 2 and Ready for build at 3. In build means the product doesn't match the file yet. If one squad does both jobs, put Explore and Ready on the feature board and delete this one. Ready for build needs the empty, loading, error, and happy-path states. A file that only shows the happy path comes back from In build as a question.

9. Hiring and people operations

Columns: Incoming, Screen, Interview, Decision, Offer, Closed. Cap Interview at the number of loops you can finish, with feedback, inside two working days. If a loop finished on Monday, the decision shouldn't wait for a weekly meeting. Closed holds rejections as well as offers. A loop is done when the written feedback is in, which can be well after the last conversation. A candidate waiting on an offer call sits in Offer with a named person and a date.

10. Finance operations

Columns: Requested, Checked, Approved, Scheduled, Paid, Filed. Cap Checked at 5. Approved is a named person. Checked means someone has looked at the amount, the vendor, and the approval rule. Scheduled means we will pay, Paid means the money moved, and Filed means someone else can find the document next quarter. A contractor payment should name the month, the amount, and the agreement. Paid without Filed is how the same invoice gets paid twice.

11. Customer onboarding

Columns: Sold, Kickoff, Setup, First value, Handoff to support. If one specialist does the setup, cap Setup at 4. Sold means the contract is signed. First value is a real event, like the first invoice sent, the first user invited, or the first report opened. Handoff names the support owner and lists the open questions.

Pick the first-value event before kickoff and write it on the card. If you change it after setup starts, say from "first invoice sent" to "customer said they are happy," nobody can tell when the card may leave the column. If the customer goes quiet, the card stays in Setup with a date and a question. Moving it back to Sold hides an account that still needs work.

12. Content and marketing operations

Columns: Proposed, Drafting, Editing, Scheduled, Published. Cap Drafting at 2 per writer and Editing at 3. Proposed holds accepted topics only; a brainstorm list belongs in a document. Scheduled means there's a date and a channel. Published means the URL is live, so a card marked Published with no URL is still in Scheduled. A draft that has sat in Editing for a week is waiting on a named editor or a named decision. Leaving it there so the writer can start a third article is the same cheat as parking blocked work in its own column.

Boards outside a codebase get the same treatment in Using a Kanban Board for Project Management Beyond Software.

Where a Jira kanban board example fits

A Jira kanban board example usually maps columns to workflow statuses: To Do, In Progress, In Review, Done. Add WIP limits on In Progress and In Review and it matches layouts 1 and 2. Jira makes sense when the team already lives there, uses its reports, and keeps statuses current. A simpler board is better when the workflow is five columns and a limit, and half the team won't learn a workflow scheme. If moving a card takes longer than the update is worth, you've picked the wrong board.

Copy a jira kanban board example only after you have decided the exit rule for each status. An In Progress status that also means "someone might look at this" will fill up, because the column is doing two jobs. Give the wait its own status, or write on the card who can unblock it. You don't need a status for every comment someone once left on a ticket.

For setup steps, and the point where a status model starts fighting the team, see How to Set Up a Jira Kanban Board (and When to Use Something Else). The other common case is a short board that's easy to share and easy to outgrow: Trello Kanban Boards for Development Teams: Where They Work and Where They Break.

Atlassian covers boards, WIP, and cumulative flow in its Kanban guide. Read the WIP and flow sections before you add columns.

Policies that keep the board true

A board stops telling the truth when people move cards to make the picture look calm. Four habits keep it honest.

Finish before you start. When Building is at its limit, the next hour goes to review, a blocked card, or verification. Starting a new feature because it's more interesting turns Review into a second backlog. If the new work matters more, put the open card back in Ready on purpose and say why. Quietly opening a fifth card in a column capped at three makes the cap fiction.

Count the wait. Six days in Review plus four hours in Building is not a four-hour task. Kanban Flow: How Work Should Move Across Your Board covers that wait. Once a week, read the two oldest cards in Review and Verify: title, age, and who can move them.

Review the rollover. At the end of the cycle, look at the cards still in Building, Review, and Verify. Either shrink the outcome or return the card to Ready and free the slot. "CSV export of all invoices, with filters" can become "CSV of one quarter, no filters" if that is what got built. Leave the original sentence on a half-built card and Done becomes a lie.

Keep one board per queue. Link cards across teams, and let each board show only the step that team owns. A support card in With engineering should point at the engineering card, and the engineering card should point back. Copy the full story into both boards and they will disagree by Thursday.

What to do after the columns feel right

Cards still arrive as Slack messages, call notes, and error reports. Someone has to turn each one into a title, a type, and an outcome before it reaches Inbox. If that job belongs to "whoever remembers," triage turns into digging through old messages.

Give that job to one person for the week. Triage ends in a yes, a no, or one question back to the asker. A message that stays in Slack and later becomes an urgent card has already skipped the Inbox exit rule.

A column count is not a forecast either. Whether Ready clears depends on how many cards you finish, not on how full Done looks. If you finish four cards a week and Ready holds eight, you have about two weeks of accepted work, plus whatever is already in Building, Review, and Verify. Splitting work to add cards to Done does not make the queue shorter.

Falrow is one place that loop can live. Requests become tickets, the board uses your stages, and the roadmap is counted from those tickets. Meeting notes can become tickets you review before they enter the queue. You can see that path in how the delivery loop runs and in tickets, triage, and workflow rules. Any of the layouts above will work in another tool too, since the columns don't depend on a specific product.

FAQ

What is a simple kanban board example for a small dev team?

Use four columns: Ready, Building, Review, Done. Cap Building at one card per person who is coding, and cap Review at two. Review means a pull request is approved. Done means the change is merged and visible in the product. Add Inbox and Verify only when cards arrive faster than you can triage them, or when "merged" and "works for a customer" are different events.

How many columns should a kanban board have?

Most software teams do well with four to seven. With fewer than four, different kinds of waiting hide in one column. With more than seven, people invent columns for rare cases and stop moving cards. Every column needs an owner and an exit rule. If you can't name both, delete the column and put that information on the card instead.

What is the difference between a kanban board and a Scrum board?

A kanban board is a continuous queue. People pull work when a column has space, and WIP limits are the constraint. A Scrum board is tied to a sprint, a set of work chosen for a timebox. The Scrum Guide defines the sprint and the backlog. You can draw a sprint on a board that looks like kanban, but if the team can add work whenever a column has room, the practice is different.

Can one kanban board cover engineering and operations?

Yes, as long as one team finishes both kinds of work and the columns still have clear exits. A small group that ships the product and onboards customers can use one board with a type on each card. Separate boards, like the finance, hiring, and support layouts, fit better when different people own the queues. Linking cards between boards works better than forcing every department into one status workflow.