Choosing a Kanban Board App: 9 Things That Matter for Dev Teams

A kanban board app is worth paying for when it shows what is in progress, what is blocked, and what can start next. For a dev team it should also record who owns each card, how long it has sat in its column, and whether the work is tied to a pull request or a bug. Nice-looking columns won't tell you any of that.

If all you need is a shared list, a simple board will do. If you ship software every week, run the app through the nine checks below before you migrate a single ticket.

What a kanban board app has to do

A kanban board is a pull system. Work enters on the left, and someone pulls it right only when they have room. The app holds that rule so the whole team works from one policy.

Three jobs matter more than themes and card covers:

• Show the state of every item without a status meeting.
• Stop new work when a column is already full.
• Make old, stuck cards obvious before review.

Atlassian's Kanban overview names the same three ideas: visualize the work, limit work in progress, and manage flow. A product either enforces them or leaves them as a sticker on the wall.

Columns are a policy

Name columns after the state of the work, not a job title. "In progress" hides too much. A small team often uses Ready (acceptance notes written, anyone can pull), Building (one card per person), Review (a pull request and a named reviewer, cap of 2 to 4), Verify (merged or staged, waiting on a check the author can't do alone, cap 2) and Done (shipped, archived weekly). Ready is a queue, so ideas stay off the board until they are small enough to pull.

WIP limits people actually hit

A WIP limit is a number on a column. When the column is full, you finish or unblock a card before starting another. If the number is only a label, people walk past it. Look for a hard stop, or at least a count that turns red in standup.

The 9 things that matter when you choose

If a tool fails three of these, it becomes a second copy of the truth sitting next to GitHub and Slack.

1. Card types that match how you ship

Bugs, features, chores and incidents move differently. A production bug may skip Ready and land in Building with a severity. A feature shouldn't. Types, or labels with required fields, stop a bug from reaching Done without a reproduction note and an error link.

2. Custom stages without a weekend of admin

You will add "Waiting on design," then drop it a month later. The kanban board app should let you add, rename and reorder columns without turning it into a schema project. Per-stage fields help here: Review demands a pull request link, and Done asks for a version or a release-note line. More than seven columns usually means two processes are sharing one board.

3. A real block state

A blocked card needs a reason, someone who can clear it, and an age. A column that people might notice is not enough. "Waiting on API credentials from the client" is a reason. "Stuck" isn't. In standup, sort by blocked, oldest first.

4. Aging you can see from across the room

Cycle time runs from start to done. Lead time runs from request to done. The board should show days in the current column and let you filter for "older than N days." (Two days in Review is an illustration here, not a benchmark.) Cards past the limit should stand out without anyone running an export.

5. WIP limits that survive Monday

Review tends to double on Monday. Limits should still hold after a bulk move, and breaking one should need an override that others can see. A cap of six doesn't help if one developer holds five of those cards, so check for per-person limits too.

6. A queue in front of the board

The board is for committed work. Slack messages, sales calls and error alerts should hit triage first, where someone accepts them, rejects them, or asks for a smaller slice before they go to Ready. A calm board and a chaotic chat will disagree within a week. Falrow turns Slack messages, call notes and Sentry errors into tickets that sit in triage until someone reviews them. A strict Inbox column works too, as long as nothing leaves it without a type and a size.

7. The link to the change, not just the task

Without a branch, pull request or commit, a card is a status rumor. The board doesn't replace Git, but it should show "PR open," "changes requested" or "merged" without anyone pasting updates. No Git connection? Require the pull request URL before a card enters Review, and check that people fill it in.

8. Policies the board can show

Each column needs an entry rule and an exit rule. Review starts with a pull request and a named reviewer, and ends with approval or a return to Building. One swimlane is enough for two speeds of work, such as interrupt bugs above planned work. Filters on label, assignee and type cover the rest.

9. Flow numbers you will look at once a week

A cumulative flow chart shows when a column is growing. For cycle time, show the spread and not only the average, because an average hides the ticket that took three weeks. Percentiles tell you how long most tickets take.

Forecasts assume the past work was similar. A Monte Carlo forecast reruns that history and gives you something like "half the time we finish this batch by the 18th." Falrow does this from ticket history. A weekly throughput spreadsheet is the rough version. Either way, don't publish a date the data can't support.

A worked example: six people, one board

Four developers, a reviewer rotation and one engineering manager. This is an illustration, not a benchmark.

Columns: Inbox, Ready (cap 10; at ten, refinement stops), Building (4, one per developer), Review (3), Verify (2), Done.

Bugs need a severity and a link. Features need a one-paragraph outcome. Chores need a definition of done in the first comment. The reviewer moves a card out of Review, either to Verify or back to Building. The author doesn't.

Monday takes 15 minutes: find an owner for each block, look at anything in Review or Building older than four days, and pull from Ready only if Building is under its limit. Friday takes 10 minutes: what reached Done, and which column grew. If Review grows two Fridays in a row, lower the Building limit before you add people.

How to compare the best kanban board options

Which one is "best" depends on who else touches the work.

• Already paying for an issue tracker? Try its board view before you buy a second subscription. For setup, and for where that board becomes the wrong place to work, see how to set up a Jira kanban board.
• For the lightest start, use a free kanban board for a month. You'll learn which columns and WIP limits you actually use before you pay for workflow rules.

Judge a demo on twenty of your own tickets, messy bugs included. Ask it what is blocked, what is old, and what can start today. Pick a tool an engineer can reconfigure, with CSV export or an API for completed cards.

Where a generic kanban app stops

A generic kanban app works for any team that moves cards around. Software teams run into four limits.

First, the card isn't the change. Branch, review, build and release live in another tab, so the board goes stale. Second, triage is half the job, and a tool with no queue teaches people to skip it. Third, sprints are optional, but a cycle with a start, a finish and a reviewed rollover is not, or Done never ends. Falrow rolls unfinished work forward only after someone reviews it, and builds the roadmap count from those tickets. Its delivery loop goes queue, pull, review, ship. A weekly Done archive plus a rollover note does the same job by hand.

Fourth, separate ops and product boards can hide that one person is already at their cap. A single WIP count per person, across boards, shows the real load. How work should move across a board covers movement in more detail. The nine checks still apply outside a codebase; only the column names change.

A fair way to trial a kanban tool

Run it for two weeks on live work, with no history migration.

In week one, only the squad uses it. Set up columns, types, WIP limits, a blocked reason and the pull request field. Watch aging, not speed. In week two, invite whoever files the most requests. If the Inbox is harder to use than a DM, they'll go back to DMs, and the tool has failed.

Keep the old tracker read-only during the trial. Keep the new one if standup got shorter and blocks got named faster. Check that it enforces rules instead of just displaying them. A contractor should be able to see their cards without an admin seat. And the database should be able to run on your machine, because a SQLite file you host and a cloud-only tenant pass very different security reviews.

FAQ

What is a kanban board app?

A kanban board app shows work as cards in columns, with a cap on each column. For a dev team it also tracks owners, blocked reasons, card age and a link to the code change. The board is the team's policy, in a place where everyone can see it.

Is Trello enough for a development team?

Trello is enough for a small team with well-defined work, as long as someone enforces WIP limits and definitions of done by hand. It gets thin once you need required fields per stage, a triage queue and a reliable pull-request link. Where it breaks: Trello for development teams.

How many columns should a software kanban board have?

Most shipping teams land on five to seven columns, counting a queue and Done. Each column needs an entry rule you can say out loud. If you can't say why a card sits in a column, merge that column into another. Extra states belong in a field, not a new column.

What is the difference between a kanban tool and a backlog tool?

A backlog tool ranks work you might do later. A kanban tool runs work that has already started, including the cap on starting more. Keep both: a queue for waiting work, and a board for pulled work only. Once "someday" ideas sit in Building, the WIP limits stop meaning anything.