In this Article:
Try Kanbanchi now
Start your free trial

Clarity is not the same as activity. A team can send dozens of messages, attend daily meetings, and still be unsure which tasks matter most, who owns each handoff, or whether a deadline is truly at risk. Most of the time, the problem is not the kanban board. It is the individual task on it. A card with a vague title, no clear owner, and a status that two people would describe differently is not tracking work. It is only recording that work exists somewhere.
This article is about that unit of work: what a task should contain, who owns it, what its status actually means, and what to do when it stops moving. If you are looking for Kanban as a project methodology (core principles, work-in-progress theory, flow metrics), start with Mastering Kanban Project Management. If you are new to Kanban boards altogether, What a Kanban board is covers the basics in a few minutes.
When there is no shared definition of progress, people describe the same task differently. One person says a task is nearly done because the first draft exists. Another says it has not started because nothing has been reviewed. A manager believes a deliverable is on track, while the assignee is quietly waiting for input from another team. Nobody is lying, and nobody is confused about the facts. They are using the same word to describe different things.
This is how teams end up with surprise delays. The work was never invisible. The meaning of its status was unclear.
A useful test: if a team member opens the board after two days away, can they understand what changed without asking five people for context? If not, the problem is almost never the number of lists. It is that the cards themselves do not carry enough meaning.
Before adding process, check whether any single card on your board answers these questions on its own.
| Question | Where the answer should live | Why it matters |
|---|---|---|
| What exactly is being done? | A task name starting with an action verb | “Website” is not a task. “Draft homepage copy” is. |
| Who owns it? | One named assignee, not a group | Shared ownership is usually no ownership |
| What stage is it in? | The list, with an agreed meaning | Everyone reads progress the same way |
| Is it blocked, and by what? | A visible status plus a comment naming the blocker | Delays surface before they hit the deadline |
| How urgent is it? | Priority field, label, or position in the list | People know what to pick up next |
| When is it due? | A date on the card | Deadline risk becomes visible early |
If a card cannot answer these, no amount of workflow design will fix it.
A card should not be a reminder to remember something later. It should contain what a colleague needs to move the task forward without messaging you first.
That does not mean every card needs a long description. It means the card should pre-empt the questions someone would otherwise ask in chat:
The last one matters more than it looks. When a decision is made in a meeting and recorded only in someone’s notes, the task loses its history. When it is recorded in a comment on the card, the task explains itself six weeks later.
This is the fix for subjective status, and most teams skip it. Lists are usually created as labels: Backlog, Ready, In Progress, Review, Done, and then left undefined. Everyone assumes the meaning is obvious. It is not. Three questions settle it for each list:
1. What has to be true for a task to enter? “Ready” is the list that causes the most trouble. Ready for whom? A task might need a brief attached, an owner assigned, and a due date set before it counts as ready. Write that down. If those things are missing, the card stays where it is.
2. Who decides it can leave? In Progress usually has an obvious answer: the assignee. Review does not. If the reviewer is the only person who can move a card out of Review, say so, and make sure the reviewer knows they own that decision.
3. Is the list claimed or assigned? Does a task enter In Progress when someone starts working on it, or when it is allocated to them? Both are defensible. Teams that never decide end up with an In Progress list containing work nobody has touched.
Here is what that looks like in practice for a content workflow:
Ten minutes of agreeing this saves more confusion than any other change on this list. It also makes the board self-policing: when a card is in the wrong place, it is now obvious rather than debatable.
Requests arrive by email, in chat, during meetings, and occasionally in someone’s head on the way to work. If there is no agreed route onto the board, two things happen. Some tasks never make it, and others get created twice by different people.
Pick one intake route and make it the only one. That might be a specific list, a form, a shared inbox, or an email address that turns messages into cards. What matters is that everyone knows where a new task lands and that nobody creates work anywhere else.
A quick rule that prevents duplicates: before creating a card, search the board. It sounds obvious, and almost nobody does it.
Not twenty. If a five-person team has twenty tasks in progress, the problem is rarely effort. It is fragmentation. Everyone is busy, everything is half-finished, and nothing reaches Done. Context-switching costs more than most teams account for.
A practical starting point is two or three active tasks per person, with everything else sitting in Ready. This is not about working less. It is about finishing before starting, which makes both delivery and blockers visible sooner.
If someone consistently has eight things on hand, that is worth a conversation about capacity rather than a note about discipline.
Clarity is not only about seeing progress. It is about seeing friction.
A blocked task should stand out immediately, not disappear inside In Progress. Some teams use a Blocked list, others use red labels or a blocked status on the card. The specific method matters less than the rule: when work cannot move forward, the board must show it.

The list titled Blocked on a Kanban board draws everyone’s attention
But visibility is only half of it. A blocker without an owner is just a warning sign. A useful blocked card explains three things:
Without those, a blocked card is a note that something is wrong, addressed to nobody.
A card sitting in the same list for two weeks is telling you something, and it is usually one of four things: it is blocked and nobody marked it, it is bigger than the card suggests, it is not actually a priority, or it belongs to someone who has too much in progress.
All four are worth knowing. None of them surface on their own.
The simplest habit is to scan for the oldest cards rather than the newest ones. Most teams look at what just arrived; the risk lives in what stopped. If a task has not moved in two weeks, either act on it, break it into smaller tasks, or archive it honestly rather than leaving it to sit.
There is a temptation to put every task from every function on one board, at maximum detail. The result is usually clutter that helps nobody: contributors cannot find their work, and nobody can see the shape of anything.
A more useful principle is that a board should hold tasks at one level of granularity. “Launch the new pricing page” and “fix typo in footer” do not belong in the same list. Use subcards or checklists for the detail underneath a larger piece of work, and keep the board itself at the level people actually plan and discuss.
Start with one workflow that has visible pain: customer onboarding, campaign production, hiring, or support requests all work well, because they involve real handoffs.
After two to four weeks, check the signals that matter: are fewer tasks getting lost, are blockers appearing earlier, and are managers asking for fewer manual updates? Those tell you more than whether the board looks tidy.
Kanbanchi is built for teams that want this kind of task-level clarity inside the tools they already use. Cards hold owners, dates, priorities, checklists, subtasks, comments, and files attached straight from Google Drive, and boards live in Drive alongside the rest of your work. For teams on Google Workspace, cards can be created directly from Gmail and dates synced to Google Calendar.
There is also a fuller overview in What is Kanbanchi?

Kanbanchi interface showcasing a Kanban board and deep Google Workspace integration
Start a free trial of Kanbanchi today
If you are comparing options more broadly, see the best Kanban project management software. And if it turns out your work needs dependencies and fixed dates as much as flow, that is a timeline question rather than a board question; Gantt vs Kanban: what to use for my project covers the difference.
At minimum: a task name starting with an action verb, one named owner, and a status that everyone reads the same way. Add a due date when timing matters, a checklist for multi-step work, and attach relevant files directly to the card. The test is whether a colleague could pick up the card and move it forward without messaging you first.
By writing it down before you need it. Agree what has to be true for a task to leave each list: a complete draft, a reviewer’s sign-off, a published UR, and who makes that call. Most disagreements about whether something is finished are really disagreements about a definition nobody wrote down.
Two or three active tasks is a reasonable starting point, with everything else waiting in a Ready list. The aim is finishing before starting. If someone consistently has many more open, that usually indicates a capacity problem rather than a discipline problem.
Find out which of four things is happening: it is blocked and unmarked, it is larger than the card suggests, it is not really a priority, or its owner has too much open. Then act: unblock it, split it, reprioritize it, or archive it. Leaving it in place makes the whole board less trustworthy.
One person. A named owner is accountable for moving the task forward and for flagging when they cannot. That does not mean they do all the work; other people can be assigned, mentioned, or asked to review, but somebody has to be answerable for the card’s progress. Shared ownership tends to become no ownership.
Read more Task Management articles here
Most task management problems are not visibility problems. The work is usually already on a board somewhere. The problem is that the cards do not say enough, the lists do not mean the same thing to everyone, and nothing surfaces the tasks that quietly stopped.
Fix those three things and the board stops being a record of what exists. It starts being something the team can actually rely on. You can try it together with Kanbanchi. Our team can help!
In this Article:
Start using Kanbanchi now
Start your free trial