Kanban is a method for visualizing work, limiting what's in progress, and making tasks flow through to the end. Here you'll see its origin, the rules, the metrics, and ready-made boards for IT, marketing, HR, and support.
Kanban is a method for making work visible, limiting how many things are in progress at the same time, and getting each item to move all the way through without sitting idle along the way. The best-known symbol is the board with columns and cards, but the board is just the visible part. What makes the method work is the rules behind it.
This guide explains Kanban from scratch: where it came from, what the principles are, how to build a real board, how to use WIP limits, which numbers to track, and how the method differs from Scrum. The examples are from Brazilian companies in different fields, because Kanban works anywhere there's work with stages.
The word comes from Japanese and means, broadly, card or signal. In current usage, "Kanban" refers to two levels. At the simple level, it's the visual board: columns represent the stages of the process and cards represent work items. At the full level, it's a management method with principles and practices that use this board to improve flow.
The difference matters. Plenty of teams set up a board with "To do, Doing, Done," hang 40 cards in "Doing," and conclude Kanban didn't work. What they built was a list with columns. Without a limit on work in progress, without clear rules for when a card advances, and without looking at how long tasks take, the board shows the mess but doesn't help fix it.
The method was born in industry. At Toyota, engineer Taiichi Ohno developed, after World War II, the so-called Toyota Production System, which aims to reduce waste and produce only what's needed, when it's needed. The kanban card was that system's signal: when a workstation consumed parts, a card went back to the previous stage requesting replenishment. Production was pulled, not pushed.
This logic of "pull work when there's capacity" was brought to knowledge work in the 2000s. The name most associated with that adaptation is David J. Anderson, who applied the method to software development teams and described it in the 2010 book Kanban. Since then, the method has spread to fields that have nothing to do with programming: agencies, HR, legal, operations, healthcare, and customer service.
A useful observation: on the factory floor, the card controls physical production, and the stock of parts is visible. In knowledge work, the "stock" is invisible, because it's ideas, requests, and emails. The board exists precisely to give that stock a visible form.
Anderson's version has a foundation that's usually summarized as change principles and management practices.
If you read the practices carefully, you'll notice that only two of them, limiting WIP and managing flow, are really different from what most teams already do. That's where the gain shows up.
The most common mistake is copying the columns from a template. Start by asking: what stages does an item really go through, from request to delivery? Write each one down. The board's columns are those stages, in the order they happen.
The minimum is "To do, In progress, Done." What's usually worth doing is splitting "In progress" into the stages that matter for your field, like "In production," "In review," and "Waiting on client." Splitting shows where work waits, and waiting is what you need to see.
A trick to avoid excess: if a column always has zero or one card, it probably doesn't represent a real stage. If a column always has 15, it probably hides two or three different stages.
Each card is one deliverable unit of work: an order, a task, a ticket, a job opening. A good card has a clear title, an assignee, a due date when there is one, and a place for a checklist, attachments, and comments. Prefer cards of similar size. If one card takes an hour and another takes a month, flow metrics lose their meaning, and it's worth breaking the big one into parts.
You can tell cards apart by type or class of service, using tags or colors: for example, "defect," "improvement," and "urgent." The point is that whoever looks at the board understands, in two seconds, what deserves attention first.
Swimlanes are horizontal bands that divide the board by some criterion. The most common are by assignee, by priority, by client, or by type of work. The assignee lane answers "who's loaded up?"; the priority lane answers "is the urgent stuff moving?" Instead of creating separate boards for each question, you group the same board in different ways.
An explicit policy is a rule everyone knows because it's written next to the board. Instead of "we usually review before delivering," it becomes: "No card leaves Review without approval from another team member." Good policies usually answer five questions.
Writing the policy on each column, even a short one, ends a good share of the "is this done yet?" arguments.
WIP stands for work in progress. The WIP limit is the maximum number of items each column accepts. When the column reaches its limit, nobody pulls a new item into it; the team first has to help finish what's there.
Starting a lot of things at once seems productive and, in practice, slows everything down. Every person who switches between five tasks spends time recovering context, and no task finishes quickly. When the limit prevents new tasks from starting, the team goes after what's stalled. The result is fewer things left half done, and each item moves through the process faster.
A Florianópolis agency, Maré Comunicação, has four people in content production: two writers and two designers. With no limit, on a typical Tuesday the board had 14 pieces in "In production" and 9 in "Internal review." No piece went out in under five days.
The team set the following limits:
| Column | WIP limit | Reasoning |
|---|---|---|
| Approved brief | No limit | It's the intake queue; it only serves for prioritizing. |
| In production | 4 | One piece per person. |
| Internal review | 2 | Only the coordinator reviews; any more than that becomes a queue. |
| Waiting on client | 6 | Depends on third parties, so the limit is looser. |
| Published | No limit | Exit column. |
In the first week, the team got stuck at "Internal review" because the coordinator had two pieces and nobody could push a third. Instead of piling up, the writers started reviewing each other's text before sending it to the coordinator, which reduced rework. The limit exposed a bottleneck that had been hidden behind the volume.
A WIP limit isn't punishment. It's a signal: when the board "locks up," the method is working and showing where attention needs to go.
You track Kanban with a few numbers, all based on dates the board already records. Tasskee's flow view brings these indicators together, and it's also worth reading the post Kanban or Gantt, which compares the board with the schedule.
| Metric | What it measures | What it's for |
|---|---|---|
| Lead time | Total time from request to delivery. | It's what the client feels: how long they wait. |
| Cycle time | Time from when work starts until it's finished. | Shows the team's speed once it picks up the item. |
| Throughput | How many items were completed per period (per week, for example). | A basis for predicting how much the team delivers. |
| Cumulative flow | Chart with the number of items in each stage over time. | Shows buildup and bottlenecks before they turn into delays. |
At Clínica Vida Plena, in Curitiba, the administrative department receives reimbursement requests. A request arrives on Monday, waits three days for someone to pick it up, is reviewed on Thursday, and is completed on Friday. The lead time is five days (Monday to Friday). The cycle time is two days (Thursday to Friday). The difference, three days, is queue. To shorten the turnaround, asking the analyst to work faster does no good: the bottleneck is at intake.
If the team completed 8, 11, 9, and 12 items in the last four weeks, the average is 10 items per week. With 40 items in the queue, an honest estimate is four weeks, and a range (three to five weeks) is more reliable than an exact date. That lets you answer "when will it be done?" based on history.
In the cumulative flow chart, each stage is a colored band. When the bands stay parallel, work is flowing. When the band of a middle stage gets fat, items are piling up there, and that's the bottleneck. If the "Done" band stays flat for many days, nothing is being delivered. It's the best chart for seeing the problem before it turns into a delay.
Both approaches are agile, but they start from different logic. See the Scrum guide for the other side of the comparison.
| Aspect | Kanban | Scrum |
|---|---|---|
| Rhythm | Continuous: work enters when there's capacity. | In fixed-length cycles (sprints). |
| Roles | None required. | Product Owner, Scrum Master, and developers. |
| Meetings | None required; the team defines its own. | Planning, daily, review, and retrospective. |
| Main control | WIP limit per column. | Scope agreed for the sprint. |
| Change midway | Allowed, if it fits within the limit. | Avoided during the sprint. |
| Typical metric | Lead time, cycle time, throughput. | Velocity and burndown. |
| Best fit | Work with unpredictable demand: support, maintenance, operations. | Projects with incremental deliveries and negotiable scope. |
You don't have to pick a side. Teams that run sprints often use a Kanban board to show the sprint's progress, and support teams that work in continuous flow set aside a sprint or a lane for internal projects. The board is the common ground.
At Bitwave, a fictional software house in Joinville with six developers, the board has these columns: Backlog, Ready to develop, In development (limit 5), In code review (limit 3), In testing (limit 2), and In production. The policy for "In code review" is that no card stays there more than one business day; past that, it becomes the first topic of the meeting. The limit of 3 in review made the team stop opening new tasks when the reviewer was overloaded.
At Rota Digital, an agency in Belo Horizonte, the columns are: Brief, Approved topic, Creation (limit 4), Internal approval (limit 2), Client approval, Scheduled, and Published. The swimlanes split by client. When a client is slow to respond, the cards sit in "Client approval," and the lane makes it clear whose turn it is. That changes the conversation with the client: instead of "we're behind," the agency shows that six pieces are waiting on their feedback.
At distributor Sul Atacado, in Caxias do Sul, each job opening is a card, and the columns are the hiring process stages: Open position, Résumé screening, HR interview (limit 6), Manager interview (limit 4), Offer, and Hired. The limit on manager interviews keeps HR from sending more candidates than the manager can handle, which used to leave good candidates waiting a week. The lead time of an opening, from posting to hire, becomes the department's main metric.
At Conecta Provedor, in the interior of São Paulo, technical support organizes tickets into: New, In diagnosis (limit 5), Waiting on customer, Technician visit scheduled, Resolved. The "Waiting on customer" policy says that after 48 hours with no response, the ticket is closed with a notice. The board lets the team see what's been stuck the longest. For anyone who needs a queue with deadlines and SLAs, Tasskee has a separate module, tickets; the SLA guide explains the concept.
In all four cases, the design is the same: real stages, a limit where there's a risk of queueing, a written rule, and a time metric.
A short meeting in front of the board, about 10 to 15 minutes, is enough for the routine: walk through the columns from right to left, from what's closest to finished to what just started. That way, the team prioritizes finishing before starting.
Tasskee's Kanban board starts from the idea that the columns are the ones from your process. You create, rename, and reorder each project's statuses, and the task changes stage with a drag. Here's what to use to apply this guide.
Board and list are on all plans, including Free. If your team works in two-week cycles, the backlog and sprint template shows how to combine the board with cycle-based planning, and the sprints feature adds backlog, burndown, and velocity.
Create your field's columns, set the limits, and track the flow. Try it free for 15 days with Pro unlocked, no credit card.
See Tasskee's Kanban boardDrag the task to another column and the whole team sees the progress.
ViewRoles, events, artifacts, epic vs. user story, and how to read the burndown.
ViewHow long a task stays in each stage, and where the process loses days.
ViewSimple Kanban that grows: Gantt, sprints, tickets, time tracking, and pricing in reais.
ViewUser stories, priority, points, and sprint, with a booking app example.
ViewOne shows today's flow, the other shows the delivery date. Learn when each one helps, why choosing between them is a trap and how to use both without doing the work twice.
ViewColumns for your process, customizable cards, and saved views. Try it free, no credit card.
