Kanban Boards in Jira: Flow Management, WIP Limits, and Service Delivery

Kanban in Jira: continuous flow and why configuration matters

Kanban is a continuous flow system: work items move through a sequence of steps, and the team pulls new work only when capacity is available. In Jira, a Kanban board is the operational view of that flow. Your goal is to make the board reflect reality (so it becomes trustworthy), then use constraints (WIP limits) and explicit policies to reduce multitasking and expose bottlenecks. Finally, you use aging and blocked signals to manage service delivery (how quickly and predictably work completes).

Key Kanban terms you will use in Jira

• Columns: the visible steps on the board (mapped to statuses behind the scenes).
• WIP limit: a cap on how many items can be in a column (or swimlane) at once.
• Swimlanes: horizontal lanes that group work (e.g., by class of service, assignee, or epic).
• Explicit policies: entry/exit criteria for each step so “Done” means the same thing to everyone.
• Aging work: how long an issue has been in progress (used to spot stuck items early).

(1) Design a board that mirrors real process steps

A useful Kanban board is not a generic “To Do / Doing / Done” template. It should mirror the real steps work goes through, including waiting states that cause delay (e.g., “Waiting for review”, “Waiting for customer”, “Waiting for deployment window”). If you hide these states, you hide the bottlenecks.

Step-by-step: design columns from your actual flow

1. List your real steps from request to delivery. Keep it to 4–8 steps to avoid noise, but include meaningful wait states.
2. Identify the commitment point: where work is accepted into active delivery (often the first “In Progress” column). Everything before that is typically “intake/ready”.
3. Identify the delivery point: where the customer/user can benefit (not just “code merged”). This may be “Deployed”, “Resolved”, or “Delivered”.
4. Group statuses into columns so each column represents a single responsibility (e.g., “Build”, “Review”, “Test”).
5. Validate with the team: walk through 3–5 recent issues and confirm each step matches what actually happened.

Example column design patterns (choose one that matches your service)

Jira configuration: map columns to statuses (without redesigning everything)

In Jira, columns display issues based on their status. You typically configure this at the board level by mapping one or more statuses to each column. This lets you keep detailed statuses while presenting a simpler flow on the board.

• Tip: If multiple teams share a workflow, avoid creating “team-specific” statuses. Instead, map shared statuses into team-appropriate columns on each team’s board.
• Tip: If you must represent a wait state, prefer a dedicated status (so aging and reporting reflect it) rather than a label.

Service delivery view: define “in progress” for metrics

For flow metrics and aging, decide which columns count as “in progress” (started) and which represent “not started” (queued). A common approach is:

• Not started: Intake/Ready/Triage (work is not yet committed).
• In progress: Build/Review/Test/Waiting (work is committed, even if blocked).
• Done: Delivered/Resolved (customer value achieved).

(2) Set and justify WIP limits to reduce multitasking

WIP limits are the core control mechanism in Kanban. They reduce multitasking, shorten cycle time, and force the team to finish work before starting more. In Jira, WIP limits can be set per column (and sometimes per swimlane depending on board setup). When a limit is exceeded, Jira visually flags the column, making the problem visible immediately.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

How to choose WIP limits (practical heuristics)

• Start with capacity: For a single-skill step (e.g., “Review”), set WIP close to the number of people who can do that work. Example: 2 reviewers → WIP 2–3.
• Lower is usually better: If you are unsure, start lower and adjust. A limit that never triggers is not a limit.
• Use tighter limits on bottleneck steps: Review and Test often become queues. Tight limits force swarming to clear them.
• Account for “waiting” columns: If you have “Waiting on Customer”, set a separate limit so it doesn’t hide stalled work inside “In Progress”.

Step-by-step: configure WIP limits on a Jira Kanban board

1. Open the Kanban board.
2. Go to Board settings (or board menu) and open Columns.
3. For each column, set a WIP limit (e.g., 5). If Jira supports separate limits for issue count vs story points in your configuration, choose the measure your team actually uses consistently.
4. Save changes and return to the board.
5. Run a short “WIP check” with the team: if any column is immediately over limit, decide whether to (a) stop starting work and swarm to finish, or (b) adjust the limit if it was unrealistic.

Justifying WIP limits to stakeholders (what to say)

WIP limits are not about slowing down; they are about finishing faster and improving predictability. A simple explanation you can use:

• Without limits: everyone starts new work, queues build up, and cycle time increases.
• With limits: we reduce context switching, unblock faster, and deliver more consistently.

If you need a numeric framing, use Little’s Law as a conceptual guide (not as a strict calculation):

Cycle Time ≈ Work In Progress / Throughput

Reducing WIP tends to reduce cycle time if throughput stays stable.

(3) Define explicit policies (entry/exit criteria) per column

A Kanban board becomes reliable when each column has explicit policies: what must be true for an issue to enter the column, and what “done” means to exit it. This prevents hidden work, reduces rework, and supports consistent service delivery.

What to write as a policy (keep it testable)

• Entry criteria: prerequisites before pulling the item into the step.
• Exit criteria: what must be completed before moving forward.
• Blocked policy: what to do when work cannot proceed (how to flag, who to notify, expected response time).
• Pull policy: who pulls work, from where, and in what order (e.g., highest priority first, or by class of service).

Example: explicit policies for common columns

How to implement policies in Jira (practical options)

• Column descriptions: Add the policy text to the column description so it’s visible where decisions are made.
• Definition-of-done checklists: Use a checklist mechanism your instance supports (custom fields or apps) for repeatable exit criteria (e.g., “tests added”, “stakeholder sign-off”).
• Automation for guardrails: Use Jira automation to flag violations (e.g., if moved to “Review” without a reviewer, add a comment or set a “Blocked” flag). Keep automation lightweight: warn first, enforce later.
• Blocked handling: Standardize how blocked work is marked (e.g., a “Blocked” field/flag) and require a reason. Policies should include who is responsible for unblocking.

Aging work visibility: spotting risk before it becomes late

In continuous flow, the biggest risk is not “how much is in the backlog” but “how long items have been in progress”. Aging highlights stuck work and helps you manage service delivery expectations.

Practical ways to make aging visible on the board

• Use card layout fields: Display fields that help diagnose delay (e.g., priority, assignee, blocked flag, due date, customer).
• Use quick filters: Create filters such as “Blocked”, “In progress > 7 days”, “Waiting on customer”, “Expedite class”.
• Use Jira’s time-in-status / control chart views if available: Review cycle time distribution and outliers; focus on the oldest items first.

Operational policy suggestion: during daily flow review, always ask “Which item is aging the most in each in-progress column, and what is the next action to move it?”

(4) Exercise: diagnose a congested board and improve throughput

This exercise trains you to read a Kanban board as a flow system. You will identify the constraint, apply WIP and pull-policy adjustments, and make aging work visible so the team finishes more work with less thrash.

Scenario: the board is congested

You open the board and see:

• Build: 8 items (WIP limit: 6) with mixed priorities.
• Review: 12 items (WIP limit: 4). Several items have been there 5–10 days.
• Test: 1 item (WIP limit: 3).
• Waiting on Customer: 9 items (no WIP limit).
• Stakeholders complain that “everything is in progress but nothing finishes”.

Step 1: Identify the bottleneck and the hidden queue

• Bottleneck: Review is over limit and aging. That is your constraint.
• Hidden queue: Waiting on Customer has no limit, so stalled work accumulates and inflates “in progress”.

Step 2: Apply immediate flow fixes (today)

1. Stop starting: Announce a temporary policy: no new items pulled into Build until Review is under its WIP limit.
2. Swarm the constraint: Reassign capacity to Review. If reviewers are scarce, pair reviewers with builders to accelerate approvals.
3. Reduce batch size: Split large review items into smaller, reviewable increments where possible.
4. Clear aging first: In Review, pull the oldest items first unless an expedite item exists.
5. Mark and manage blocked work: For items in Waiting on Customer, ensure each has a next follow-up date and a clear question. If no response after a defined period, apply your timeout policy (e.g., close as “Pending info” or escalate).

Step 3: Adjust WIP limits and pull policies (this week)

Make changes that prevent recurrence:

• Set a WIP limit for Waiting on Customer (e.g., 5). Policy: if the limit is hit, the team must resolve/close stale items or escalate before accepting more customer-dependent work.
• Lower Build WIP (e.g., from 6 to 4) to reduce feeding the Review queue.
• Keep Review WIP tight (e.g., 4) and add an explicit policy: reviewers respond within 1 business day; if not possible, reassign.
• Define pull order: (1) Expedite (if any), (2) oldest aging item, (3) highest priority. Write this on the board so it’s consistent.

Step 4: Make aging and service delivery visible (ongoing)

1. Create a quick filter for aging work (example JQL below) and review it daily.
2. Update card layout to show fields that explain delay (blocked reason, customer, due date).
3. Track a simple service expectation: for example, “Most standard items complete within X days.” Use your control chart/cycle time view to set X based on actual data, then monitor outliers.

Example JQL for aging and blocked visibility

Adapt field names to your Jira configuration:

-- In progress for more than 7 days (using status category and updated time as a proxy if needed)  project = ABC AND statusCategory = "In Progress" AND updated <= -7d  -- Items waiting on customer  project = ABC AND status = "Waiting on Customer"  -- Blocked items (if you have a flag/field)  project = ABC AND "Blocked" = Yes

What “improvement” looks like on the board

• Review column stays at or under its WIP limit most of the time.
• Build column has fewer items, but items move faster to Done.
• Waiting on Customer does not grow without bound; stale items are actively managed.
• Aging outliers are discussed daily with a clear next action, not just observed.