Blog · 8 October 2026

Jira kanban board: set one up, limit the work, keep it flowing

A Jira kanban board is a board with no sprints: work enters on the left, moves right through columns that match your workflow, and the team pulls the next card only when it has room. To get one, create a space from the Kanban template (or add a kanban board to a space you already have), map each column to a workflow status, and set a maximum on the columns where work tends to pile up. That is the whole setup. The harder part, and the one most guides skip, is what feeds the board: routine work that should appear on a schedule, and usually appears only when somebody remembers it.

This guide covers both halves. The first is the board itself, done with Jira's own settings. The second is keeping the left-hand column honest.

The short answer #

• New to kanban in Jira? Create a space from the Kanban template. You get a board, a workflow and the columns To Do, In Progress and Done, ready to use.
• Already have a space and want a kanban view of it? Create a new board, choose kanban, and point it at a filter for that space.
• Cards piling up in one column? Turn on column constraints and give that column a maximum. The header turns red when the limit is passed.
• Routine tickets missing from the board? Create them on a schedule, either with a Jira Automation scheduled rule or with Recurring Work Items for Jira, so they land in To Do on their own.

Kanban or scrum: which board do you need? #

Both board types show the same issues in the same columns. The difference is how work is committed.

Pick kanban when the work arrives continuously and cannot wait for the next planning meeting. IT operations, a service team, a content team and a maintenance rota all fit this shape. If your team plans in two-week chunks and reviews at the end of each, a scrum board will serve you better, and Jira for sprint planning is the place to start.

Many teams end up with both: a scrum board for the product work and a kanban board, in the same or a separate space, for the steady stream of operational tickets that would otherwise wreck every sprint.

How to create a kanban board in Jira #

There are two routes, depending on whether the work already lives somewhere.

Start a new space from the Kanban template #

1. In Jira, select Create space (older sites call this Create project).
2. Pick the Software development category, then the Kanban template.
3. Name the space, pick a key, and create it.

You now have a board with three columns and a workflow behind them. For most teams that is the right place to start: add columns later, once you can see where work actually waits.

Add a kanban board to an existing space #

1. Open the space, then the board switcher at the top of the board, and choose to create a board.
2. Choose Kanban board.
3. Build it from an existing space, or from a saved filter if the board should show work from several spaces.

The filter is the board. Whatever the filter's JQL returns is what the board shows, so a board for "all operational work across three spaces" is just a filter such as project in (OPS, INFRA, SEC) AND labels = routine. Get the filter right and the board follows.

Configure the columns #

Columns are where a kanban board earns its keep. Each column is mapped to one or more workflow statuses, and a card moves column when its status changes.

Open the board, then More actions (•••), then Board settings, then Columns. From there:

• Add a column for every stage where work genuinely waits. "In review" and "Waiting for customer" are common additions. A column nobody waits in is just an extra drag.
• Map statuses to columns by dragging them. A status that is not mapped to any column is invisible on the board, which is a common reason for "my ticket disappeared".
• Keep Done on the right, and let it be the only column mapped to resolved statuses.

Set work limits with column constraints #

Limiting work in progress is the core idea of kanban, and Jira calls it column constraints. Atlassian's column documentation (as of October 2026) puts it plainly:

"Setting constraints on each workflow state is a crucial part of kanban, so that you can ensure that work is continually flowing through the pipeline." Atlassian, Configure columns, as of October 2026

In the same Columns settings, choose to count Work item count or Work item count, excluding subtasks, then type a minimum or maximum under each column's name. On the board, the same page says, a column over its maximum gets a red header and one under its minimum gets a yellow one. Two details worth knowing from that page: the constraint only changes the colour, it does not stop anyone dragging a card in, and it counts every card in the column even when a quick filter hides some of them.

A sensible first limit is the number of people who work that column, plus one. Lower it when the column is often red for a reason the team accepts.

Swimlanes and quick filters #

A kanban board with forty cards in one view is hard to read. Two settings fix most of it.

• Swimlanes split the board into rows. By assignee is the usual choice for a team; by query works when you want a fast lane, for example priority = Highest in its own row at the top.
• Quick filters are one-click JQL. Useful ones for a kanban board are Only my issues, Blocked (flagged is not EMPTY) and Routine (labels = routine), which lets the team see the scheduled work apart from everything else.

Keep the board fed: the routine work #

Here is the part a kanban board cannot do for itself. The board shows what exists. It does not create anything, so every recurring job your team owns (the monthly access review, the weekly backup check, the quarterly licence audit, the Friday dependency update) only reaches the To Do column if a person creates it.

That works until it does not. Somebody is on holiday, the checklist lives in their head, and the access review nobody created is the one nobody did. On a kanban board, a missing card looks exactly like no work, which is the most reassuring way to be wrong.

There are three ways to put routine work on the board.

With a Jira Automation scheduled rule #

Automation's Scheduled trigger runs a rule on a fixed interval or a cron expression, and a Create work item action puts the ticket in the space. Labels set in that action let the board's Routine quick filter find it. The cron syntax and its traps are in Jira cron expression, and what a rule costs against your allowance is in Jira Automation pricing.

With Recurring Work Items for Jira #

Recurring Work Items for Jira is an app that lives in each space's own page. A space administrator writes a rule once (a schedule, an issue type, a summary, a description, labels, an assignee, a due date) and the issue is created at each occurrence. The rules page shows each rule's next run and its history, so a skipped or failed run is visible rather than silent.

Three settings matter most for a kanban board:

• Labels. Give every rule the same label, such as routine, and the quick filter above shows the scheduled work in one click.
• Non-working days. A rule can skip a weekend or a holiday, or move to the next or previous working day, so a daily card does not appear on a day nobody works.
• The overlap rule. A rule can create nothing while the previous issue is still open. On a kanban board this keeps one card per job in flight, rather than a stack of identical tickets nobody finished, which also stops the scheduled work quietly breaking your column limits.

Titles and dates can carry the occurrence's own date, for example Access review {{now.monthName}} {{now.year}}, so each card says which cycle it belongs to. The token list is on the tokens page.

A worked example: an operations kanban board #

A three-person operations team runs one kanban board for everything that is not a project.

Swimlanes are by query: an Urgent lane on top, then everything else. Quick filters are Mine, Blocked and Routine.

The routine work comes from five schedules: a weekly backup restore test, a weekly patch window ticket, a monthly access review, a monthly certificate expiry check and a quarterly licence audit. Each carries the routine label, skips non-working days, and creates nothing while the previous one is open. The team never creates those five by hand, and on Monday morning the To Do column already shows the week's routine alongside whatever arrived from the service desk. More patterns for this kind of team are in Jira for IT operations.

When the manual way is enough #

Not every board needs scheduled tickets. Create routine work by hand when:

• There are one or two recurring jobs and the same person always does them.
• The job is irregular, triggered by an event rather than a date. That is an Automation rule with an event trigger, not a schedule.
• You are still finding the board's shape. Run it for a few weeks first. Once you know which jobs come back every cycle, schedule those.

Common kanban board problems #

• A card is missing from the board. Its status is not mapped to a column, or the board's filter excludes it. Check Board settings, then Columns, for unmapped statuses.
• Done is full of old cards. Move finished work out with a release, or narrow the board's filter so it only shows recently resolved items.
• Every column is red. The limits are wishful. Raise them to what the team actually carries, then lower them one at a time.
• The board looks quiet, but the routine work is overdue. Nothing created it. Schedule it, as above, and check the rule history rather than the board.

A kanban board is only as truthful as what is on it. Set the columns and limits once, then make sure the work you know is coming arrives without anyone needing to remember it. If that is the gap, start with one recurring rule for the job your team forgets most often.