Como montar um quadro Kanban do zero (passo a passo)

O que é um quadro Kanban

Um quadro Kanban é uma representação visual do fluxo de trabalho de um time: colunas representam as etapas por onde o trabalho passa (por exemplo, "A fazer", "Em andamento", "Em revisão", "Concluído") e cartões representam cada item de trabalho — uma tarefa, uma campanha, uma vaga a preencher. O cartão anda da esquerda para a direita conforme o trabalho avança, e qualquer pessoa que olhe o quadro entende, em segundos, o que está sendo feito, por quem e onde as coisas estão travando.

A palavra "kanban" vem do japonês e significa algo como "cartão de sinalização". O método nasceu na Toyota, no chão de fábrica, e foi trazido para o trabalho do conhecimento mantendo os mesmos princípios: visualizar o fluxo, limitar o trabalho em andamento e puxar trabalho novo apenas quando há capacidade — em vez de empilhar tarefas sobre pessoas já sobrecarregadas.

Montar um quadro Kanban bem feito não é escolher um template bonito: é um exercício de honestidade sobre como o trabalho realmente flui no seu time — incluindo as esperas e os retrabalhos que ninguém gosta de admitir. Este passo a passo mostra como fazer isso do zero, com exemplos de times de desenvolvimento, marketing e RH.

Passo 1: mapeie o fluxo real, não o ideal

O erro mais comum ao montar um quadro Kanban é desenhar o processo como ele deveria ser, e não como ele é. O quadro ideal da cabeça do gestor tem quatro colunas limpas; o fluxo real tem a espera pela aprovação do jurídico, o vai-e-volta com o cliente e uma etapa de "esperando o financeiro liberar" que ninguém documentou.

Antes de abrir qualquer ferramenta, reúna o time e reconstrua a trajetória de dois ou três trabalhos recentes, do pedido à entrega. Pergunte: por onde esse item passou? Onde ficou parado, e esperando o quê? Quem precisou aprovar? Houve retrabalho? Anote cada etapa e cada espera.

Um exemplo concreto: a equipe de marketing da Renata achava que o fluxo era "briefing → produção → publicação". Ao mapear três campanhas reais, descobriu que toda peça passava por revisão da marca, que metade voltava para ajustes e que a publicação dependia de uma janela do time de mídia. O fluxo real tinha seis etapas, não três — e duas eram esperas por outros times.

Regra prática: se o trabalho espera em algum ponto com frequência, essa espera merece aparecer no quadro. Colunas como "Aguardando aprovação" não são feias — são o quadro dizendo a verdade. É nelas que você vai enxergar os gargalos do fluxo mais tarde.

Passo 2: transforme as etapas em colunas

Com o fluxo mapeado, cada etapa vira uma coluna. A estrutura mínima é "A fazer → Em andamento → Concluído", mas quase nenhum time real cabe em três colunas. A pergunta que decide se algo merece coluna própria é: o trabalho muda de estado ou de responsável nessa etapa? Se sim, coluna. Se é só um detalhe da execução, não.

Alguns exemplos de quadros para times diferentes:

Time de desenvolvimento: Backlog → A fazer → Em desenvolvimento → Em revisão de código → Em teste → Concluído

Time de marketing: Ideias → Briefing aprovado → Em produção → Revisão da marca → Agendado → Publicado

Time de RH (recrutamento): Vaga aberta → Triagem de currículos → Entrevistas → Proposta enviada → Aguardando resposta → Contratado

Repare que os três quadros contam histórias completamente diferentes — e é assim que deve ser. Copiar o quadro de outro time é copiar o fluxo de outro time. Se você lidera uma equipe fora da tecnologia, vale ler sobre Kanban fora da TI: os princípios são os mesmos, mas as etapas mudam muito.

Duas dicas de desenho:

• Comece com menos colunas e adicione conforme a dor aparecer. Um quadro de cinco colunas que o time entende vale mais que um de doze que ninguém atualiza.
• Separe "em andamento" de "em espera" quando a espera for relevante. "Em revisão" (alguém trabalhando) é diferente de "Aguardando revisão" (parado na fila). Misturar os dois esconde tempo de espera — e tempo de espera costuma ser onde o prazo vai embora.

No TeamBOX, por exemplo, o board da sprint já vem com uma coluna de "Dependência externa" justamente para dar nome a esse tempo em que o item está fora das mãos do time — uma das esperas mais comuns e mais invisíveis.

Passo 3: defina o que é "pronto" em cada coluna

Um quadro sem critérios de saída vira campo de interpretação: cada pessoa move o cartão quando acha que terminou. O resultado são itens em "Concluído" que voltam, revisões feitas pela metade e discussões do tipo "mas eu achei que já estava pronto".

A solução é escrever, para cada coluna, uma política de saída: o que precisa ser verdade para o cartão avançar. Não precisa ser burocrático — duas ou três frases por coluna bastam, visíveis para todo o time.

Exemplo do time de desenvolvimento do Caio:

• Sai de "Em desenvolvimento" quando: código commitado, testes locais passando, pull request aberto.
• Sai de "Em revisão" quando: aprovado por pelo menos um colega e comentários resolvidos.
• Sai de "Em teste" quando: cenários do critério de aceite validados em homologação.

Exemplo do time de RH da Fernanda:

• Sai de "Triagem" quando: pelo menos cinco currículos aderentes enviados ao gestor da vaga.
• Sai de "Entrevistas" quando: parecer registrado de todos os entrevistadores.
• Sai de "Proposta enviada" quando: candidato confirmou recebimento e prazo de resposta combinado.

Esses critérios são primos da Definition of Done do Scrum — a diferença é que no Kanban você define um "pronto" por etapa, não só no final. É esse detalhe que evita que o quadro vire teatro: o cartão só anda quando o trabalho andou de verdade.

Passo 4: limite o trabalho em andamento (WIP)

Aqui está a parte que separa um quadro Kanban de um mural de tarefas: o limite de WIP (work in progress — trabalho em andamento). É um teto combinado de quantos itens podem estar em cada coluna ao mesmo tempo. Por exemplo: no máximo 3 itens em "Em desenvolvimento", no máximo 2 em "Em revisão".

Por que limitar? Porque começar é fácil e terminar é difícil. Sem limite, o time inicia dez coisas ao mesmo tempo, todas avançam devagar, e nada é entregue. Com limite, quando a coluna enche, a regra é clara: ninguém puxa item novo — todo mundo ajuda a terminar o que está travado. O limite de WIP transforma "estou ocupado" em "estamos entregando".

Como escolher o número? Não existe fórmula mágica, mas há pontos de partida razoáveis:

• Comece com algo próximo de 1 a 1,5 itens por pessoa que atua naquela etapa. Três desenvolvedores? Limite de 3 ou 4 em "Em desenvolvimento".
• Colunas de espera (aprovação externa, dependência de terceiros) também merecem limite — se dez itens estão "aguardando aprovação", o problema não é o time, é o fluxo, e o quadro precisa gritar isso.
• Ajuste a cada duas ou três semanas: se a coluna nunca enche, aperte; se vive estourando e virando exceção, investigue antes de afrouxar.

O limite vai incomodar — e é para incomodar. Quando a Renata colocou limite de 2 na coluna "Revisão da marca", a fila de peças esperando revisão ficou escancarada. A conversa que veio disso ("precisamos de mais um revisor ou de critérios mais simples para peças pequenas") era exatamente a que o time evitava havia meses. Para calibrar esses números com mais profundidade, veja o artigo sobre limites de WIP no Kanban.

Passo 5: combine a política de puxar (não empurrar)

No sistema empurrado, quem distribui trabalho é o gestor: terminou algo (ou não), chega tarefa nova na sua mesa. No sistema puxado, é o contrário: quando alguém conclui um item e há espaço no limite de WIP, essa pessoa puxa o próximo item mais prioritário da coluna anterior.

Isso muda três coisas na prática:

1. A fila precisa estar priorizada. Se o time puxa "o próximo item do topo", alguém precisa garantir que o topo é o mais importante. Essa é a função do gestor (ou do dono do produto) no Kanban: cuidar da ordem da fila, não distribuir tarefa por tarefa. As técnicas de priorização de backlog valem inteiras aqui.
2. Ninguém "guarda" trabalho. Item não tem dono antes de ser puxado. Isso evita o padrão de cada pessoa ter sua pilha particular de dez tarefas — que é só o excesso de WIP escondido em nível individual.
3. Urgência vira exceção com nome. Todo time tem incêndios. Em vez de furar a fila silenciosamente, crie uma raia de expedição: uma linha do quadro para itens realmente urgentes, com limite de 1. Se a raia de urgência vive cheia, o problema é de planejamento, e o quadro está mostrando isso.

A cerimônia que sustenta tudo isso é uma conversa curta e frequente na frente do quadro — muitos times usam a daily para isso. A pergunta muda de "o que você fez ontem?" para "o que está impedindo os itens mais à direita de saírem do quadro?". Olha-se o fluxo, não as pessoas.

Exemplos completos: três quadros de verdade

Para amarrar os passos, três quadros completos com colunas, limites e política de puxar:

Desenvolvimento (5 pessoas):

• Backlog → A fazer (limite 5) → Em desenvolvimento (limite 4) → Revisão de código (limite 2) → Teste (limite 2) → Concluído
• Puxar: quem termina puxa do topo de "A fazer". Revisão tem prioridade sobre código novo (senão a coluna do meio entope).

Marketing (4 pessoas):

• Ideias → Briefing aprovado (limite 4) → Em produção (limite 3) → Revisão da marca (limite 2) → Agendado → Publicado
• Puxar: designer livre puxa o briefing aprovado mais antigo. Peça reprovada volta para "Em produção" já contando no limite — retrabalho ocupa capacidade e o quadro precisa mostrar isso.

RH / recrutamento (2 recrutadoras):

• Vagas abertas → Triagem (limite 3) → Entrevistas (limite 4) → Proposta (limite 2) → Aguardando resposta → Contratado
• Puxar: fechou uma vaga? Puxe a vaga aberta mais crítica (ordem combinada com os gestores toda segunda). Vaga parada 10 dias em "Aguardando resposta" dispara conversa com o candidato.

Note que nenhum desses quadros tem sprint, estimativa ou papel novo. Kanban é método de fluxo contínuo — se seu time trabalha em ciclos fechados com meta, talvez o caminho seja outro, e a comparação Kanban vs Scrum ajuda a decidir (ou a combinar os dois).

Erros que transformam o quadro em depósito

Todo quadro Kanban abandonado conta a mesma história: ele parou de dizer a verdade e o time parou de olhar. Os padrões mais comuns:

• Quadro que ninguém atualiza. Se o cartão anda só na véspera da reunião, o quadro é um relatório, não uma ferramenta. Solução: atualizar no momento em que o trabalho muda de estado, e fazer a daily olhando para ele — quadro desatualizado fica constrangedoramente visível.
• Coluna "Em andamento" com 30 itens. Sem limite de WIP, o quadro vira depósito de boas intenções. Cada cartão parado há semanas é um pequeno "não" que ninguém teve coragem de dizer. Limite de WIP e uma limpeza honesta ("isso vai ser feito mesmo? senão, arquiva") resolvem.
• Cartões vagos. "Ajustar campanha", "Ver com o Paulo". Cartão bom diz o resultado esperado: qualquer pessoa do time deveria entender o que é "pronto" lendo o título.
• Colunas que não refletem mais o fluxo. O processo mudou, o quadro não. Revisite as colunas a cada mês ou dois: coluna sempre vazia pode sair; espera nova merece entrar.
• Quadro pessoal do gestor. Se só o gestor move cartões, o time não tem quadro — tem vitrine. Quem faz o trabalho move o cartão, e as políticas (limites, critérios de pronto) são combinadas em conjunto, não impostas.
• Ignorar o que o quadro mostra. O pior erro é o mais sutil: a coluna de aprovação vive entupida há meses e ninguém age. O quadro não resolve problema nenhum sozinho — ele só torna o problema impossível de ignorar. Agir sobre o que ele revela é trabalho de gestão.

Checklist para montar o seu esta semana

1. Reúna o time e mapeie o caminho real de 2–3 trabalhos recentes, incluindo esperas e retrabalhos.
2. Desenhe as colunas a partir desse mapa — comece simples, com colunas de espera onde a espera dói.
3. Escreva 2–3 critérios de saída por coluna, visíveis para todos.
4. Defina limites de WIP iniciais (≈1 a 1,5 itens por pessoa nas colunas de trabalho ativo) e combine a regra: coluna cheia, ninguém puxa — todos ajudam a desafogar.
5. Combine a política de puxar: fila priorizada, item sem dono até ser puxado, raia de urgência com limite de 1.
6. Marque uma conversa diária (ou a cada dois dias) de 10 minutos na frente do quadro, olhando da direita para a esquerda: o que falta para os itens quase prontos saírem?
7. Agende uma revisão do quadro em 3–4 semanas: colunas fazem sentido? Limites estão certos? O que o quadro revelou que vocês ainda não atacaram?

Feito é melhor que perfeito: o primeiro quadro do seu time vai estar errado em alguma coisa, e tudo bem — a graça do Kanban é justamente evoluir o processo olhando para dados reais do fluxo, uma pequena melhoria por vez.