What Is a Kanban Board? A Practical Guide for Software Teams

A kanban board is a visual pull system. Each piece of work is a card, and the card moves left to right through columns that match how your team actually finishes work. You start something new only when a later column has room. That one rule is the difference between a useful board and a decorated to-do list.

Software teams use the board to see what has been requested, what is being built, what is stuck, and what shipped. This guide covers columns, cards, limits, policies, a worked setup, a few metrics, and the ways boards go stale.

How a kanban board works

Work arrives on the left. Someone pulls a card into the next column only when that column is under its limit, and the card stays visible until it meets the exit criteria for done. Pulling is the default. Nobody hands out a batch on Monday morning.

Three ideas sit under that motion.

Visualize the real path. Columns name the states work passes through. They are not the departments on an org chart. If tickets sit in code review for two days, code review is a column. If "In progress" hides review, testing, and waiting on a product answer, you cannot see the wait.

Limit work in progress. A work-in-progress (WIP) limit is the maximum number of cards allowed in a column, or in a group of columns. When the column is full, people finish or unblock a card before they pull another. If the limit never binds, the board is just a status report.

Manage flow, not utilization. Someone juggling five half-done tickets delivers later than someone who finishes one before starting the next. Queue time, the hours a card waits with nobody working on it, is often the largest part of lead time. The board is there to show those waits.

You also need explicit policies: who may pull, what "ready" means, and what happens when a card is blocked. When the workflow changes, change the columns. A column that exists only because the template shipped with it should go.

The parts that make the board true

Columns

Start with the fewest columns that still show waiting. A team that ships often can begin with five:

Column	What it means	Illustrative WIP limit
Ready	Agreed, clear enough to start, unblocked	A short cap, so the queue stays ordered
Build	Someone is changing code	About one card per person, or a team cap
Review	Waiting on review, or being reviewed	Lower than Build
Verify	On a test environment, not accepted yet	2 or 3 for the team
Done	Meets the done policy	Archive on a fixed day

Those limits are a sketch for a team of about six engineers, not a benchmark. If Review is always empty and Verify is always full, verification is the constraint, and the limits should reflect that.

Split a column when it mixes two kinds of wait and you keep making the wrong call because of it. A "Build" column that includes both "waiting on design" and "writing code" looks busy while half its cards sit idle. A separate Blocked column is optional. A blocked flag on the card usually works better, because the card stays in the column where it stopped and still counts against the limit. Parking blocked work off to the side makes the board look healthier than the system is.

Done needs a sentence or two. "Merged to main" and "running in production" are different promises, so pick one and put it where the people pulling cards can see it.

Cards

A card is one unit you can finish within a normal stay on the board, or one slice of a larger effort that can move on its own. Title it as an outcome. "Invite links expire after 72 hours and show a specific error" beats "Work on invites."

Keep the fields short until you feel a real gap:

• A title a teammate understands without opening a doc
• Type, if bugs, features, and chores follow different pull rules
• An owner, once the card is in Build (empty while it sits in Ready)
• Age, or the date it entered Build, so old cards stand out
• A link to the spec, the error, or the thread that spawned it
• A blocked reason, cleared when the block ends

Priority stickers on every card turn into noise. If everything is high priority, the order of Ready is your real priority, so reorder Ready when news arrives and skip a second ranking system that disagrees with it.

WIP limits

Set each limit a little below the number of cards that usually sit in that column. You want mild tension, where finishing is the way to start something new. A limit that never binds is decoration. If people override it every day, either the number is too low for how work arrives or the team hasn't agreed that finishing beats starting.

Count cards, not people. A limit of six means six cards, even in the week two people are out. Adjacent columns can share a limit. Build and Review might share one cap, for example, so clearing review is how you earn the right to open new build work.

Expedites are a written exception. Allow one slot for a production incident or a dated commitment. When that slot is full, the next urgent item either waits or replaces the current expedite. An unlimited fast lane turns into a second system nobody can see.

Policies

Write policies next to the board, in language someone can read in a minute.

• Pull only from the top of Ready unless that card is blocked.
• A card moves to Review only when someone else can review it without chasing context.
• The reviewer is not the author, unless the team is one person.
• A card that sits past a set number of days is the first topic in the next standup. Until you have your own history, two or three days is a fair tripwire for a team that ships often.
• Done cards leave the visible board on a fixed day so the column does not become a trophy case.

Policies are working agreements, not a handbook nobody opens. When the same argument happens twice, change the policy.

A worked example you can copy

This kanban board example is a composite, not a customer story. Copy the shape and swap in your own names.

Team. Six engineers, one engineering manager, and one product manager, releasing continuously. Support and sales do not drag cards themselves. Their requests arrive as tickets and go through triage.

Columns and limits. A weekly refill keeps Ready at about ten cards. Build is capped at 6, Review at 3, and Verify at 2. Done is cleared every Monday.

One card. "Invite link expires after 72 hours and shows a specific error." Product writes the acceptance notes during triage. Build has five cards, so an engineer pulls this one in. Once her pull request is open, she moves the card to Review. Review already holds three cards, so instead of pulling a new feature she reviews someone else's card first, and that card moves on to Verify. Only then, with Build still under its cap, does someone pull the next Ready card.

What they refuse. They won't add a "Waiting on product" column that swallows ten cards and drops them out of the WIP count. A card waiting on a product answer stays where it stopped and keeps counting. The product manager sees a full column and answers, or the team pauses that card under a written swap rule.

Monday. They look at cards older than four days, check whether Verify was the fullest column, and confirm Ready is still in the right order. They don't re-estimate the whole board. A card that fails verification goes back to Build, and the return stays visible.

Platform and support-engineering teams often keep those columns and change the expedite rule, since more of their work arrives as interrupts. More layouts, including ops teams, are in 12 examples from real software and ops teams.

Columns on a screen versus a real pull system

When people say "kanban style board," they usually mean columns on a screen. That's where it starts. A board earns the name once WIP limits bind, pull policies are real, and blocked work stays inside the count.

You can build that in a general tool or in a tracker made for software. The hard part is the agreement to stop starting. Before a lightweight tool becomes your system of record, read Where Trello-style boards help development teams, and where a simple column layout breaks. Specialist trackers add issue types, queries, and release views, which help when the board is one view over a ticket rather than the only record. How to set up a Jira board, and when a team should use something else walks through that tradeoff.

Keep one board that the team treats as current. A second board for leadership, updated by hand, will have drifted by Friday.

Project work on the same board

A kanban board for project management works when the project is a stream of deliverables that can each finish on their own: a migration cut into shippable slices, a launch list of real tasks, a customer implementation with stages you can exit. It works badly when the work is one indivisible date and the board is just a picture of percent complete. Percent complete is not a column.

For a dated effort, use the board to show the sequence that remains. Every card should still be something you can pull and finish. A card called "Phase 2" that can't move until twenty other cards move is a container. Keep containers on a roadmap or a parent ticket, and put the slices on the board.

Cross-functional projects stall when each function has its own private board and nobody owns the handoff. One shared board with columns named for the handoffs beats four departmental boards plus a weekly reconciliation. The WIP limit on the handoff column is what gets the next group to pull. Using the same pull system past the engineering org goes further on non-software work. Inside engineering the rule doesn't change: states, caps, and a done policy that means accepted.

Triage, the daily pass, and replenishment

Three conversations keep the board honest. They can be short meetings or written updates, but you can't skip them just because the tool has columns.

Triage decides what may enter Ready. Look at new tickets, not the whole history, and send back anything a teammate couldn't pull tomorrow and know when it's done.

The daily pass walks the board from right to left: Verify, then Review, then Build. For the oldest card, ask what would move it today.

Replenishment refills Ready up to a cap, often weekly. Product brings candidates. The team rejects work that can't be pulled and splits cards that would sit in Build too long. The promise here is to keep Ready true. It isn't a promise to finish a fixed list by a date, unless you deliberately add that policy.

If you also run Scrum, the sprint backlog is already a WIP limit with a timebox, so don't treat it as an infinite Ready column on top of that. The Scrum Guide defines the sprint backlog and the increment, and it doesn't require any particular board product. State in your policies whether the end of a sprint resets the board or whether unfinished cards stay put and keep counting against WIP.

What to measure

Measure flow. The board should not become a scoreboard for individuals.

Lead time runs from a stated start until Done. The start is usually entry to Ready or the original request. Publish whichever one you use.

Cycle time runs from the start of Build until Done. Time spent waiting in Ready is mostly an ordering choice.

WIP is the number of cards in the active columns. If it's always over the limit, the limit is a wish.

Throughput is the number of cards that reached Done in a week. Only compare weeks when the cards are a similar size.

Age is how long each active card has been active so far. It warns you earlier than average cycle time, which only counts finished cards.

Use a percentile rather than a single average, because a flattering mean can hide a long tail. If you forecast, base it on your own finished cards and publish a range.

If your tool draws cumulative flow, a queue shows up as a widening band. Stop pulling into the column before it and spend time on the wide one. Adding people upstream makes the queue worse. How work should move from column to column covers what to do when one stage is the constraint.

How boards fail while looking busy

No limits. You can see status but not flow. This week, put one team limit on the active columns.

Columns named after people. These freeze when that person is out. Columns should be states, and avatars show owners.

Done means "my part is finished." The card disappears while the user still can't do the thing. Move the done policy to the last real handoff, or add that column and give it a limit.

The board and the code disagree. A card says Review while the pull request is still a draft. Fix the board, or derive the state from the pull request. Once nobody trusts the board, chat replaces it, and chat has no WIP limit.

Quiet overrides and a stale Ready column. If the same person steps around the limit every day, either change the number in public or hold it. If the top of Ready is months old, replenishment should delete those cards. A long Ready column pulls attention away from finishing.

What has to sit under the board

A board shows state. It doesn't create the work, review the code, or remember why a ticket exists. Each card should point to a ticket that holds the conversation, the acceptance notes, and the link to the change. When the ticket and the card diverge, stop and pick one system of record. Updating both by hand doubles the chores and halves the accuracy.

If requests start in chat, on a call, or as an error, the ticket under the card has to survive that handoff. Falrow's tickets, triage, and workflow rules are one way to keep that record tied to the board, with stages you define. The board still needs your WIP limits, because no product can supply the agreement to stop starting. For the path from request to shipped change, see how that delivery loop runs. Charts only help once the history is honest.

Atlassian's overview of Kanban boards is a clear second pass over the same terms. The product vocabulary differs, but the mechanics are the same: show the path, cap the queues, pull when there is room, and write down what done means.

A first week

1. List the states work actually passes through. Aim for four to six columns.
2. Write a one-sentence done policy on the Done column.
3. Put current work on the board, one card per effort someone is touching. Finish or explicitly pause the rest.
4. Set one WIP limit on the active columns, a little under today's count if that count is high.
5. Define Ready so a teammate could pull the top card without a meeting.
6. Run the next standup from right to left.
7. After five working days, look at aged cards and at which column ran full. Change one limit or split one column, but don't redesign the board.

In week two, add the expedite rule and the blocked-card rule. The team doing the work sets the limits, because they're the ones who feel the queues. Whoever orders Ready owns priority. Someone, often the engineering manager, has to protect the limit when a stakeholder wants one more card started. Stakeholders can get a weekly view of Done, the aged cards, and the top of Ready. They don't need their own set of columns.

FAQ

Is this the same as a scrum board?

No. A Scrum board usually holds one sprint's commitment and resets on a cadence. A Kanban system limits work in progress all the time and refills Ready as capacity frees up. Plenty of teams put a sprint backlog on columns, and that's fine as long as you pick one story and stick to it. Either unfinished work is a missed sprint commitment, or it's aged work that still counts against the limit. Say which one you mean so standup doesn't turn into an argument about words.

How many columns should we use?

Use the smallest number that still shows where work waits. Four to six is enough for most software teams: a ready column, two or three active states, and done. Add a column only when a mixed state hides a queue you keep mismanaging, such as review buried inside build. Extra columns feel precise, but they add moves, and more moves mean more cards left in the wrong state.

What is a good WIP limit?

One that sometimes blocks a pull while still leaving people with legal work to pick up. For a build column, about one card per person is a common first setting when the work is mostly independent. Treat that as a hypothesis. If it never binds, lower it. If you override it every day, raise it once and then hold it. The right number is the one your team will actually enforce next week.

Can one board hold bugs and features?

Yes, if they share the pull rules and the done policy. Mark bugs with a type so you can filter them, and decide whether a production incident may use the single expedite slot. A separate bug board often turns into a place to hide from the WIP limit. Keep one flow unless bugs are handled by a different group with its own capacity. In that case the handoff is a column or an exit, not a private list nobody counts.