How you build your columns
Task statuses are managed in settings, alongside project statuses, priorities, labels and issue types. A status is created with a name and a colour, and the columns appear on the board in the order you created them — there is, for now, no reordering or renaming of an existing status, so you settle the scheme early and correct it by deleting and re-adding. One detail that matters for organisation: statuses are defined at workspace level, not per project, so the same column scheme applies across all your projects. Statuses named "done", "completed" or "closed" are treated as completion — the burndown, velocity and the project completion rate all depend on them.
Kanban board or sprint board
These are not two products but the same board seen through different filters. Without sprints you work in continuous flow: all the project tasks, on your own columns. With an active sprint, you narrow the board to the current sprint and additionally get a burndown, a sprint goal and velocity over closed sprints. Switching moves and migrates nothing, because sprint membership is just a field on the task: fill it and the task is in the sprint, clear it and it returns to the backlog. History, comments, dependencies and time entries are untouched in both directions.
What the column counters tell you
Every column shows three figures taken from the present state: how many tasks it holds, how many of them are past their due date, and how many story points they total. A review column that grows from one day to the next, or that accumulates most of the points, is the signal that work is piling up there. The counters are snapshots, though, not time series: the board draws no cumulative flow diagram and measures neither lead time nor cycle time, because tasks do not carry the moment they entered each column. For change over time you have the sprint burndown and the velocity chart.
What the board does not do
The board sets no WIP limits: it tells you how many tasks are in a column, but it neither blocks nor warns on a breach. It has no swimlanes — separating teams or types of work is done through filters and labels, not horizontal bands. It has no automation rules: moving a card changes the status and writes to the log, and that is all — it assigns nobody, applies no label and forwards nothing. And it has no integrations with code repositories or other tools: no pull request moves a card, because the service does not, by construction, talk to external systems.
