Kanban Board

How a software development Kanban board works

Software teams usually extend the basic three columns to match how their work actually flows. A common software development Kanban board looks like this:

Backlog → Ready → In progress → Code review → Testing → Done

Each card is one piece of work: a feature, a bug or a small improvement. A card usually shows a short title, who is working on it, and a label for priority or type. Cards move from left to right as work progresses.

The rules that make Kanban work

Columns and cards are only the visible part. Kanban as a method adds a few practices:

• Work-in-progress (WIP) limits. Each column has a maximum number of cards. If "Code review" is limited to three and already holds three, nobody starts new work; they help clear reviews instead. This is the most important rule and the one most often skipped.
• Pull, not push. People pull the next card when they have capacity, instead of having work piled on them.
• Explicit policies. Each column has a clear definition. Does "Done" mean merged, tested or deployed?
• Measure flow. Track how long cards take from start to finish, called cycle time. Short, predictable cycle times are a sign of a healthy process.

A concrete example

A team notices that cards pile up in "Testing" while "In progress" keeps filling. The board makes the bottleneck obvious: one tester is covering the output of four developers. The options become clear too: add automated tests, have developers test each other's work, or lower the WIP limit so developers stop starting new work and help clear testing. Without the board, the team would simply feel busy and behind.

Kanban vs Scrum

• Kanban: continuous flow with no fixed iterations. Work is pulled in as capacity frees up, and priorities can change at any time for cards not yet started. No roles are required. The key measures are cycle time and throughput. It suits support, maintenance and steady streams of incoming work.
• Scrum: work is planned in fixed-length sprints, with defined roles (product owner, Scrum Master and developers). Priorities usually change between sprints rather than during them. It suits product teams building toward a clear goal each sprint.

Many teams mix the two and use a Kanban board to track work inside Scrum sprints.

Common pitfalls

• No WIP limits, which turns the board into a to-do list and hides overload.
• Stale cards that nobody moves, making the board unreliable.
• Giant cards such as "Build the app." Break work into pieces that can be finished in a few days.
• A board that does not match reality, because the real status lives in chat messages.

What to ask your development team

• Can I see the board, and does it reflect what is actually happening?
• What are your WIP limits, and how often do you hit them?
• How long does a typical card take from start to done?
• Where do cards usually get stuck?

If you want an outside view of how your development process runs, our tech consultation team can review it with you.