The usual framing is that a board is the grown-up version of a list — that you start with a to-do list and graduate to kanban once you are serious. That is not what separates them. They are optimised for two different questions, and both questions are legitimate.
- A list answers what should I do next. It is ordered, and its whole value is that the top item is the answer.
- A board answers where is everything right now. It is grouped by state, and its value is that nothing can be in two places or in no place.
Notice that the second question only matters when work has states worth distinguishing, and when somebody other than you cares about the answer. That is the actual dividing line.
When a list is the better tool
For one person doing sequential work, a list beats a board and it is not close. You know what is in progress, because you are the one doing it. A board asks you to move a card to tell yourself something you already knew, which is pure overhead dressed up as method.
- You work alone and hand nothing over.
- Most items are small and finish the same day they start.
- The hard part of your day is choosing, not coordinating.
- The work does not need to be visible to anybody else.
There is one more advantage that gets underrated: a list is honest about volume. Forty items on a list look like forty items. Spread across five board columns, forty items look like progress.
When a board earns its overhead
A board pays for itself as soon as work has to change hands, or as soon as several jobs are open at once and each one is stuck on something different.
- Two or more people, and work passes between them. "In review" as a column removes the question of who has it.
- Several parallel projects at different stages. The board is the only view where you can see all of them at once.
- Waiting is common. A column for blocked work is the same fix as the waiting state a list system needs anyway.
- Someone asks for status. A board answers that without you writing a summary.
The one kanban rule you cannot skip
Kanban is not the columns. The columns are the visible part. The mechanism is the limit on how many things may be in progress at once, and a board without one is a board that will fill up.
Pick a number for the doing column — for one person it is genuinely two or three, not eight — and treat it as a rule rather than a suggestion. When it is full and something new arrives, you have to finish or explicitly park something before starting. That constraint is uncomfortable, and it is the entire benefit: it converts a vague feeling of being overloaded into a visible decision about what to stop.
| Situation | Use |
|---|---|
| One person, sequential work | A list |
| One person, several projects stalled on different things | A board |
| Two or more people with handovers | A board, with a limit |
| Client asks for status regularly | A board they can see |
| You mainly need to decide what to do next | A list |
| You mainly need to see what is stuck | A board |
What small teams usually end up with
The stable answer for most small service teams is not one or the other. It is a board of projects and a list inside each one.
The board carries the projects, in columns describing where each stands — quoted, active, waiting on the client, ready to invoice. Inside a project, the tasks are an ordered list, because within one job the useful question really is what next. Two views, two questions, no duplication.
The failure mode to avoid is maintaining both for the same items: a board because it looks organised and a list because it is faster to use. Two representations of the same work drift apart within a week, and then neither is trusted.
Board and list on the same tasks
The useful version is one set of tasks you can look at either way, rather than two systems to keep in sync. That is how tasks and projects work in Oplero.