How to Set Up a Jira Kanban Board (and When to Use Something Else)
By Sebastiaan Jansen · · 8 min read
A Jira Kanban board is a view in Jira Software that shows issues as cards moving through columns, with optional work-in-progress (WIP) limits. You create it from a project or a saved filter, map statuses to columns, put limits on the columns where work waits, and keep the filter to one team. This guide covers creating a kanban board in Jira, the settings that change how a jira kanban board behaves, and when another tool fits better.
For the idea before the product, read what a Kanban board is and how software teams use one. The rest assumes a Jira Software project and permission to create a board.
How to set up a Jira Kanban board
The project holds issues, the workflow is statuses and transitions, and the board is a filtered view grouped into columns. Renaming a column leaves the workflow alone, but a workflow edit changes what the board can show.
1. Choose Kanban, then choose the source
In Jira Cloud, open the project sidebar or Boards → Create board and select Kanban. Scrum expects a backlog and sprints. Kanban is a continuous queue where you pull the next item when you have capacity.
- From a project: fastest, when one team owns one project.
- From a saved filter: JQL for one project plus a label, or two projects on one workflow, when the project is bigger than the team's work.
Name the board for the team and the work. "Payments intake" will still mean something in six months, and "Kanban board 3" won't.
2. Map statuses into a few columns
Open Board settings → Columns. A status is a workflow state. A column is what people see, and several statuses can share one.
| Column | Statuses inside it | What the column means |
|---|---|---|
| Queue | Backlog, To Do | Accepted, not started |
| Building | In Progress | Someone is changing the code |
| Review | In Review | Waiting on a reviewer, not the author |
| Done | Done | Merged or released, per your definition |
Four columns is enough for most teams. Give an unused status its own column and it fills up with stale cards.
A missing ticket is usually an unmapped status: if no column owns it, the issue does not appear. After any workflow change, reopen Columns and place every live status.
3. Put WIP limits where queues hide
A WIP limit is a number on a column. Once the column goes past it, Jira highlights it, but a drag still works unless you add automation or a workflow condition. The highlight exists to show overload.
Limit Building and Review. Leave Queue unlimited or very high, and skip Done. For five engineers, a Building limit of 8 does nothing, while a limit of 3 starts to bite in week one. If people keep pulling past a red column, lower the number or name who is allowed to exceed it.
4. Backlog, swimlanes, and filters
Turn on the Kanban backlog only if someone ranks it. An ungroomed list of hundreds is a search problem, and JQL handles that better.
Swimlanes (by assignee or epic) help in a meeting, so turn them off afterward. Keep two or three quick filters ("My work", "Bugs"); with twelve of them the board starts to look empty. On the card, show what people actually read at standup, and drop story points if nobody uses them when talking about flow.
5. Write the pull rule in one sentence
Jira will not enforce this, so put it in the board description:
"Pull the next Queue item into Building only when your current item is in Review or Done, and only when Building is under its WIP limit."
A worked example: payments, five engineers
These numbers come from one team and aren't a benchmark. Five engineers share project PAY: support bugs plus stories from a product manager, deploys several times a week, no sprints.
The filter is project = PAY AND resolution = Unresolved ORDER BY rank ASC. On-call gets a quick filter instead of a second board: issuetype = Bug AND priority in (Highest, High). A board that is both the team queue and the company status wall gets ignored by both.
| Column | Statuses | WIP |
|---|---|---|
| Queue | To Do | none |
| Building | In Progress | 4 |
| Review | In Review | 3 |
| Done | Done | none |
PAY-418, "Refund webhook retries forever," lands in Queue. Building is at 3 of 4, so an engineer moves it to In Progress. The next day Review sits at 4 against a limit of 3, the column highlights, and the team holds PAY-422 until a review clears.
Hiring notes, roadmap items, and a platform migration stay off this filter. A broken limit should mean the team is overloaded, so unrelated work stays out of these columns.
Each week, check Review items older than two days and In Progress items with no comment for three days. Queue items older than 30 days get closed, split, or deferred. You'll see the same shape in these Kanban board examples from software and ops teams: one team, columns for real waits, and a limit on the wait that hurts most.
Kanban in Jira: the settings that keep the board true
The board is quick to create. It goes wrong in settings nobody reopens.
Dragging a card to Done does not always set Resolution. Filters on resolution = Unresolved, and many dashboards, follow that field, so finished cards stay visible. Use a post-function or automation to set Resolution when an issue enters Done and clear it when it leaves.
Rank is LexoRank, not Priority, and it is global. Reorder issues on one board and you reorder them on every board that shows them. Two ranked views of one filter only work if both teams accept one order.
Track cycle time rather than a point total; Kanban does not need story points. The control chart, under Reports, shows the time between the statuses you limited. Hide checklist sub-tasks, or WIP will count every checkbox as its own piece of work.
Atlassian's Kanban boards guide names the same core: show the work, limit what is in progress, and manage the flow. Menus change between Cloud releases; those three don't.
When the board starts lying
A company-wide filter with dozens of assignees is a status report, and nobody can pull from it at standup. Split it by team and give leadership a dashboard of counts.
Columns like "Waiting on Design" and "Waiting on Platform" turn into a museum unless someone clears them. How work should move across a board gives the test: every column is either active work or a queue with an owner. If nobody owns it, delete it and track the wait with a flag or a linked issue.
A column that stays red for a month teaches people that red is normal. And if tickets get opened after the pull request, because the discussion happened in Slack and the error showed up in Sentry, the board is recording last week.
Give the team board admin, or they'll route around columns they can't change. Keep workflow admin tighter, since a workflow edit hits every project that shares it.
When to use something else
Stay if the team already lives in Jira, the work is issues on one workflow, and people will actually pull. The control chart and dashboards are enough for many teams, and you don't need a new product to rename columns.
Add another system when the board is not the record.
Often the intake is calls, Slack threads, and production errors, and someone retypes each one into Jira. That copy is only as fresh as their patience. Falrow starts from those requests: Slack messages, call notes, and Sentry errors become tickets, and coding agents plan from the git repository under the team's rules, with version-checked writes. The ticket flow is the record, so nobody transcribes anything twice. That's a different job from drawing columns.
A control chart shows history. The odds of finishing a set of tickets in three weeks depend on throughput and a model. Falrow runs Monte Carlo forecasts from ticket history (2,000 runs) and shows cycle time percentiles, with triage and custom stages in the ticket workflow. Whatever chart you use, Marketplace apps included, check that its inputs are items the team actually finishes.
A single small project with no workflow gates can get by on a free kanban board. If you're comparing products, what to demand from a kanban board app covers filters, WIP, permissions, and a record of who changed a ticket.
Finish the setup this week
Set up one team filter, four columns or fewer, WIP limits on Building and Review, two quick filters, and one pull rule. Recheck the limits at the second standup. If the board still doesn't match how code ships after two weeks, another column won't fix it. Either some work never becomes an issue, or each issue is really a project.
FAQ
How do I create a Kanban board in Jira?
In Jira Software Cloud, use Create board, choose Kanban, and pick a project or a saved filter. Map statuses to columns and set WIP limits on the active columns. You need permission to create a board. If Kanban is missing, the project may already be team-managed, or a site admin has restricted who can create boards.
What is the difference between Kanban and Scrum boards in Jira?
Kanban is continuous flow, with optional WIP limits and no sprint end date. A Scrum board is a backlog plus a timeboxed sprint. Scrum reporting tracks commitment and velocity, while Jira Kanban reporting tracks flow through columns. Match the board to how the team already plans. You can pull on a Scrum board, and you can misuse Kanban as a sprint that never ends.
Why are issues missing from my Jira Kanban board?
Either the filter excludes them or their status is not on a column. Check Board settings → General, then Columns. The Kanban sub-filter also hides completed issues older than a set number of days, on purpose. And if you can't see a project, you won't see its cards on a shared board.
Should a software team stay on Jira for Kanban?
Stay if issues already live there, one workflow is enough, and the team pulls with WIP limits. If a few people only need columns, use something simpler. If work arrives in Slack, on calls, or as production errors and only becomes a ticket later, add a system that starts from requests. Falrow is built for that case; it's in private beta, with access by request. Having the ticket exist before the work is finished matters more than the column layout.