A well-designed kanban board makes work visible, limits unfinished tasks, and gives a team a shared way to decide what happens next. This guide provides a reusable structure for building a kanban board for software, marketing, operations, client work, or personal projects, along with practical rules for ownership, prioritization, work-in-progress limits, and ongoing improvement.
Overview
A kanban board represents work as cards that move through a sequence of stages. Each column describes a state in the workflow, such as “Ready,” “In progress,” “Review,” or “Done.” The board can be physical or digital, but an online kanban board is usually easier to share, search, update, and connect to other work systems.
The goal is not to create the most detailed project plan. It is to create a reliable view of the work as it exists now. A useful board answers four questions quickly:
- What work is waiting to begin?
- What is currently in progress?
- Where is work blocked or waiting for review?
- Who owns the next action?
Start with the actual workflow rather than a standard set of columns. A software team may need separate stages for development, testing, and deployment. An operations team may need intake, triage, approval, and fulfillment. A personal kanban board may only need “To do,” “Doing,” and “Done.” The best project tracking board is specific enough to reflect reality without becoming difficult to maintain.
Template structure
Use the following structure as a starting kanban board template. Rename, combine, or split columns after observing how work moves through them.
- Inbox or intake: Capture requests, ideas, issues, and tasks before deciding when they should be handled. This prevents new work from entering the active workflow through scattered messages or memory.
- Ready: Place work here only when it has enough information to begin. A ready card should have a clear outcome, an owner or intended owner, and any important dependencies identified.
- In progress: This column shows work receiving active attention. Set a work-in-progress limit so the team does not start more tasks than it can reasonably advance.
- Review or verification: Use this stage for testing, approval, editing, security checks, or another defined quality step. Keep review visible rather than hiding it in comments or chat.
- Blocked or waiting: Add this column when delays are common or meaningful. A blocked card should explain what it is waiting for and who can help remove the obstacle.
- Done: Define what completion means before using the column. “Done” might mean deployed, delivered to a customer, documented, approved, or closed in the relevant system.
Not every board needs every column. A simple flow might be Backlog → Ready → Doing → Review → Done. Avoid using “Doing” as a general holding area for every task that has been selected. If a card is waiting on someone else, move it to a waiting or blocked state so the team can see the difference between active work and delayed work.
Each card should contain enough information to support the next decision. Include a concise title, a description of the expected result, the owner, priority, due date when relevant, and links to requirements or supporting files. Use labels for stable categories such as team, work type, customer, system, or risk. Do not create a label for every detail; excessive metadata makes a board harder to scan.
How to customize
Design columns around handoffs
Columns should represent meaningful changes in responsibility or status. Ask, “What must happen before this card can move?” If the answer changes substantially from one stage to another, a separate column may be useful. If two columns have the same owner, decision, and exit criteria, combining them may make the board clearer.
For technical teams, a workflow might be Backlog → Ready for development → Building → Code review → Testing → Released. For marketing, it could be Ideas → Briefed → Drafting → Review → Scheduled → Published. For business operations, consider Requested → Triaged → Approved → In progress → Quality check → Complete.
Set work-in-progress limits
A work-in-progress limit caps the number of cards allowed in a column or group of columns. Begin with a small, practical limit rather than treating it as a permanent formula. For example, a two-person team might start with two active cards in development and one card in review. The purpose is to expose bottlenecks and encourage finishing before starting more work.
When a limit is reached, the next action is usually not to increase the limit. First ask whether someone can help finish, review, test, clarify, or unblock existing work. If the same constraint persists, adjust the workflow, staffing assumptions, or card size based on what the board shows.
Make ownership explicit
Assign one directly responsible person to each active card, even when several people contribute. Shared responsibility can make it unclear who should provide the next update. Add collaborators, reviewers, or watchers separately when the tool supports them.
Break down cards when they remain in one column for too long or require several unrelated outcomes. A card such as “Improve onboarding” is a goal, not necessarily a trackable task. More useful cards might include “Audit the signup form,” “Write the onboarding email,” and “Measure activation after the change.” The right size depends on the workflow, but each card should represent a result that can move independently.
Connect prioritization to the board
Keep the backlog ordered or grouped by a visible decision rule. You might rank work by customer impact, urgency, risk reduction, effort, or a combination of these factors. A task prioritization matrix can help when a backlog contains competing requests, but avoid letting a scoring system replace judgment. Priority should explain why one item is ahead of another.
Check capacity before committing to a large batch of work. The team capacity planner can be paired with the board to compare planned work with the time actually available for delivery, support, meetings, and maintenance.
Examples
Software development
Use columns such as Backlog, Ready, Development, Code review, Testing, Deploying, and Done. Add a blocked indicator for dependencies, environment problems, or unanswered requirements. Keep bugs, features, and maintenance work distinguishable with labels, while using the same flow where their handoffs are similar. A focused bug tracking board setup can help a small team decide which details belong on each card.
IT support and operations
A help desk board might use New, Triage, Assigned, In progress, Waiting for requester, Escalated, and Resolved. Capture impact, urgency, affected service, and the next response directly on the card. Keep escalations visible rather than allowing them to disappear into a high-priority queue. See the IT help desk kanban workflow for a more detailed model.
Marketing and content
A content board can move cards through Ideas, Briefed, Drafting, Editing, Approved, Scheduled, and Published. Add the target audience, format, owner, review requirements, and publication destination to each card. A content calendar kanban template can be adapted for campaigns, documentation, product announcements, or recurring editorial work.
Client and personal projects
For client work, try Requested, Scoped, Awaiting approval, In progress, Client review, Revisions, and Delivered. For personal work, use To do, Doing, Waiting, and Done, with a low limit on the Doing column. A small board is often more effective than a complex system when one person is responsible for selecting and completing the work.
When to update
Review the board when the underlying work changes, not merely because a calendar reminder says to redesign it. Revisit the workflow after adding a new team, tool, approval step, product line, support channel, or deployment process. Also review it when cards regularly skip columns, remain blocked, or require explanations that the board does not currently capture.
Use a short review at the end of a work cycle or project milestone. Look for recurring signals:
- A column is almost always empty or almost always full.
- Cards wait longer for review than they take to complete.
- Work enters the board through chat, email, or meetings without a consistent intake step.
- Several cards have no clear owner or next action.
- The team starts work before requirements or dependencies are ready.
- “Done” cards return to active work because completion criteria were unclear.
Take one practical action after each review: rename a confusing column, add an exit criterion, lower a work-in-progress limit, split oversized cards, or remove an unused field. Avoid changing several rules at once, because the team will have difficulty identifying which change improved the flow.
To build your board today, list the last several tasks your team completed and write down the real stages they passed through. Turn those stages into columns, add only the cards that are genuinely ready or active, assign an owner to each active item, and set an initial work-in-progress limit. Then schedule a brief review after the board has been used long enough to reveal a pattern. This approach produces a project tracking board that evolves with the work instead of becoming another process the team has to work around.
