What is a Kanban board?
A Kanban board makes the current flow of work visible. A card might represent a customer issue, a small product change, or a release task. Its column tells readers what state the work is in. Useful cards also explain the intended result, owner, next action, and anything preventing progress.
Atlassian's board guide describes visualizing work with cards and columns. Its work-in-progress guidance explains using limits to expose bottlenecks and avoid taking on more simultaneous work than the team can handle. The examples below apply those ideas to a small fictional SaaS; the chosen limits are starting assumptions, not universal capacity rules.
You can maintain the board on paper, in a spreadsheet, or in a project tool. The important agreement is what each state means and what the team does when work cannot move. A beautifully arranged set of cards with no shared policy still leaves those decisions unresolved.
Example 1: a small SaaS delivery board
Our original fictional reporting SaaS uses Backlog, Ready, Doing, Review, and Done. Ready means the task is understood well enough to start. Doing means someone is actively responsible for completing it. Review means the implementation exists but still needs its defined checks. Done means those checks passed and the result is available in the intended environment.
The team starts with a limit of two cards in Doing and one in Review. A limit is a prompt to finish, help, or resolve a blockage before pulling another task. It does not imply that two people are equally available or that every card takes the same amount of effort.
The completed CSV has one card in each state. The Review card has a failed permission case; it remains in Review with a blocked marker. Moving it to a separate parking column would hide the fact that review capacity is occupied.
| Backlog | Ready | Doing (limit 2) | Review (limit 1) | Done |
|---|---|---|---|---|
| K1: Saved report presets | K2: Explain empty export | K3: Add export filter | K4: Verify permission checks — blocked | K5: Update help link |
Define entry and exit rules for every column
Write policies that another teammate could apply without asking the founder to interpret them. A task should not enter Ready just because its title sounds understandable. Give it a specific outcome, relevant constraints, an owner for unanswered questions, and a check that establishes completion.
For Doing, make the next action visible and keep the card small enough to finish without hiding several unrelated outcomes. For Review, identify the checks and the reviewer. If only the author can review their own work, describe the alternative check rather than inventing independent approval.
Done is a shared agreement. In this example, merged code alone is insufficient: the intended environment must contain the change, the required checks must pass, and any needed help update must be available. Your team may have different release boundaries; document them on the board.
| State | Entry condition | Exit condition |
|---|---|---|
| Backlog | A need or request is recorded | Selected for clarification |
| Ready | Outcome, scope, and completion check are clear | Capacity is available and an owner pulls it |
| Doing | An owner starts within the active-work limit | Implementation and required author checks are ready |
| Review | A reviewer and check list are named | Checks pass and intended availability is confirmed |
| Done | The shared completion policy is met | No further movement; follow-up work receives a new card |
Handle blocked work without losing its age
Keep a blocked card in the state where it is stuck. Record when the blocker was noticed, why progress stopped, who owns the next action, and when it will be reviewed. A card waiting for a vendor reply still represents unfinished work even if nobody can type code on it today.
For K4, the fictional reason is that a forbidden export request returned data in a test environment. The next action belongs to Engineering, and the card stays within Review's limit. That gives the team a clear reason to investigate before sending another change for review.
Do not respond to every blockage by raising the limit. Help finish the oldest relevant item, split an unrelated scope, or explicitly decide to suspend work and record that decision. If exceptions are frequent, review the workflow and capacity assumptions rather than treating every exception as surprising.
Example 2: a solo founder's support and delivery board
A solo founder may need a simpler workflow: Inbox, Clarify, Active, Waiting, and Resolved. Start with one Active item if that matches how you work. Treat Waiting as unfinished and review it daily; otherwise customer questions can disappear into a quiet column while new work keeps arriving.
Separate a response from a fix. A support card may be resolved when the customer receives an accurate explanation, while a linked product card remains unfinished. Conversely, deploying a fix does not establish that the customer can complete the task. State which result the card represents.
Use the weekly schedule guide to protect time for customer responses and delivery. If urgent work arrives, make the interruption visible, record what paused, and review whether the active-work limit still represents reality. Keep private customer details out of a public board.
Review flow before adding more cards
At a short board review, inspect blocked and aging cards first, then look for capacity to pull new work. Ask where a card last moved and what concrete action will move it next. Counting cards without reading the workflow can reward splitting work into meaningless fragments.
If you track cycle time, define its start and end states and include unfinished aging work in the conversation. Five completed tiny fixes do not tell you how long the large stuck item will take. Use timestamps consistently and describe any excluded work.
Choose the view for the decision. A roadmap communicates direction. A Gantt schedule coordinates tasks against dates. The board helps manage flow today. A deadline on a card may be useful, but it does not turn the board into a dependency-aware schedule.
Download the board and policy templates
The CSV contains the five fictional cards, including outcome, owner, state, next action, blocker, and illustrative timestamps. Blank rows let you add your own items. Import it into a tool that supports CSV or edit it in a spreadsheet; import behavior varies, so review the state mapping before using it.
The text template contains the column policies, initial limits, blocked-work rules, a review agenda, and a blank section for your workflow. For tool-specific implementation, the Linear planning guide explains how its planning objects fit together. Sources and resources checked October 27, 2026.