Pisando fundo: Trello + kanban para seu time ágil decolar

Executar um processo scrum ou kanban vai muito além de usar a ferramenta certa. Na verdade, tem muito mais a ver com a qualidade do trabalho em equipe e, no final, com o valor da entrega para seus clientes.

Mas sim, é verdade... Uma boa ferramenta ajuda sim o time a colocar todos os detalhes do desenvolvimento do produto de forma visual. Assim, todo mundo pode usar seu poder mental para resolver problemas complexos durante os Sprints.

O Trello é ótimo para gerenciar processos de Sprint, porque os times acham fácil de acompanhar o que está acontecendo e os recursos não atrapalham o trabalho em grupo, como acontece com ferramentas mais complexas.

Como o Trello é extremamente flexível, você pode experimentá-lo de diversas maneiras, até descobrir a que funciona melhor para seu time ágil.

Conversei com centenas de times que usam o Trello para gerenciar processos scrum e kanban e o Power-up do Corrello para acompanhar o processo através de dashboards.

Esses times ágeis variam de pequenos - mas em rápido crescimento - a times grandes e bem estabelecidos. A partir dessas conversas, algumas práticas comuns se destacaram no uso do Trello para kanban e scrum, que vamos conhecer agora.

De volta ao básico: configurando seu quadro do Trello para kanban e scrum

Vamos dar uma olhada no que esses times ágeis de sucesso são capazes de fazer com o Trello aplicando a metodologia do kanban ou scrum.

Evidentemente, todos sabem muito bem o que é kanban e como usar. Mas, e você? Sabe o que é o sistema kanban?

Bem, vamos ao básico!

Assim, vamos ter certeza de que todo mundo têm o mesmo nível de conhecimento sobre alguns fundamentos do Trello para kanban e scrum antes de entrarmos em alguns problemas mais complexos:

Quadro básico para scrum/kanban

Os elementos-chave de um quadro de scrum básico para um time de desenvolvimento de software são:

1. Uma lista de backlog do Sprint: Ela é preenchida no início do sprint e (todos contamos com isso!) terminada até o final do sprint 😊.

2. Uma ou mais listas de "Trabalho em andamento": Na captura de tela acima, temos "Dev" (Desenvolvimento), "Code Review" (Revisão de Código) e "Test" (Teste), mas, é claro, isso deve ser adaptado para o seu processo específico. Vale a pena dividir seu processo em mais do que uma única lista "Em andamento". Assim você poderá ver como os cartões fluem por todas as etapas do processo no quadro.

3. Uma lista de “Concluído”: Ele deve conter todos os trabalhos já concluídos (além de um bom lembrete de tudo o que você realizou!).

Um quadro kanban simples ficaria muito parecido com o quadro do Sprint acima, mas no lugar do “Sprint Backlog”, você teria uma lista "Ready for Dev" (Pronto para Desenvolver) na extremidade esquerda do quadro.

E lembre-se: tanto o scrum, quanto o kanban são metodologias ágeis.

Cada novo trabalho é colocado na lista "Pronto para Desenvolver" quando eles estão prontos para serem codificados. Note que os cartões são priorizados de cima para baixo, isto é: os que estão no topo devem ser realizados primeiro!

Assim que o time tem disponibilidade para assumir mais tarefas, o trabalho é arrastado de "Ready for Dev" (Pronto para Desenvolver) e vai fluindo pelo quadro até ser concluído e colocado na lista “Done” (Concluído). 🚀

E aí, pronto para mais listas?

O quadro kanban acima mostra um conceito bastante útil para quem usa a metodologia kanban.

Ele é usado por alguns times para acompanhar cartões que por algum motivo ficaram parados no fluxo. Isso os destaca em relação àqueles que estão sendo trabalhados normalmente.

Pense assim: se um cartão de um quadro do Trello para kanban leva cinco dias para passar pelo processo, ele deveria ser trabalhado ativamente por cinco dias sem parar, certo? Ou, então, será que ele deveria ficar esperando, enquanto outras tarefas interdependentes são concluídas?

Se você pudesse reduzir o tempo de espera, você poderia trabalhar mais rápido sem que ninguém tivesse que fazer qualquer trabalho adicional! (O quê?). Vamos dar uma olhada em um exemplo de mais um quadro do Trello para kanban para ficar mais claro:

Aqui podemos ver três cartões em "Dev" (Desenvolver) e um na lista "Test” (Testar). Existem também dois cartões na lista "Ready for Code Review” (Pronto para Revisão de Código).

Se você analisar o quadro kanban com sua equipe, você poderia perguntar por que ninguém pegou nenhum cartão da lista "Ready for Code Review” (Pronto para Revisão de Código) antes de entregar um cartão da lista "Dev" (Desenvolver).

As listas "Ready for...” (Pronto para...) ajudam você a acompanhar se os cartões estão parados e, mais importante, evidenciar para o time que os cartões estão disponíveis para a próxima etapa do processo, mas não estão sendo trabalhados de forma cadenciada.

Assim, a equipe pode ser pró-ativa e começar a trabalhar mais rapidamente (sem trabalhar mais).

Essas listas “Pronto para...” também mostram mais facilmente o processo está acumulando tarefas na lista de espera.

No exemplo acima, não há nenhum cartão na lista "Test” (Testar) para ser trabalhado depois que cartão "Cycle Time chart" for concluído.

Um quadro do Trello para kanban mais simples, pode não evidenciar tão bem quando não tem ninguém revisando cartões.

Isso porque os cartões estariam parados na lista “Code Review” (Revisão de Código), sem que qualquer código estivesse sendo revisado na realidade.

Lembre-se: as listas “Pronto para...” quase dobrarão o número de listas "Em andamento" que você tem.

Talvez você não queira criar muitas etapas, mas, se achar que pode ser útil, é fácil testar se uma lista funciona (ou não) e arquivá-la depois.

A estrutura de listas flexíveis do Trello faz com que isso seja apenas mais uma alteração. Também é possível implementar as listas "Pronto para ..." apenas para as partes do processo que você acha que seriam as mais beneficiadas (segundo minha experiência, é sempre uma revisão de código que precisa desse tipo de lista 😉).

Como arquivar trabalhos concluídos

Ambos os quadros do Trello para kanban acima têm uma única lista "Done" (Concluído), que sugere algumas formas de arquivar (ou não) as tarefas concluídas:

1. Nunca arquive ou remova cartões da lista "Concluído"; nós vamos lidar com eles quando o final dos tempos chegar! ❌

2. Arquive esses cartões periodicamente, quando "ninguém aguentar mais". (Listas longas podem ser ruins de gerenciar.) 🗃

3. Arquive listas "Concluído" semanalmente (mas lembre-se: você corre o risco de remover o registro do que foi concluído recentemente). 😬

Algumas opções muito usadas:

1. Listas “Done” (concluído) para cada sprint / semana / mês, dependendo das preferências do time. Com esse procedimento, você cria uma nova lista "Concluído" a cada semana e renomeia a antiga "Concluído - semana 8/10/18 – 14/10/18". Essas listas vão pouco a pouco para a direita e podem ser arquivadas quando não forem mais necessárias.

2. Um quadro inteiro dedicado a cartões arquivados para armazenar trabalhos anteriores. Isso geralmente é organizado por meio de listas específicas para cada sprint ou semana. Os cartões na lista “Concluído” são todos movidos para o quadro de arquivo periodicamente. Isso deixa o quadro principal um pouco mais organizado e mantém um histórico completo de tudo que foi feito e quando foi feito.

A propósito, essa lógica de separar fluxos de trabalho de repositórios é descrita em detalhes no texto workflow online.

Sobretudo, qualquer uma dessas opções é uma ótima maneira de criar um histórico de entregas que seja fácil de pesquisar, além de manter o quadro principal bem limpo.

A descrição dos cartões

Eu vejo muitos times ágeis armazenando detalhes do trabalho que precisa ser feito diretamente na descrição do cartão, ao invés de vincular a arquivos do Google ou outros documentos.

O uso do Markdown (uma linguagem de programação simples para formatar o texto, detalhes aqui) permite muitas opções para formatar sua descrição no cartão.

Uma regra que você deve seguir é: se a descrição ficar muito grande, divida o cartão em duas tarefas.

Os links são usados para detalhes adicionais, como wireframes (representações gráficas simples de um site), modelos de uma interface do usuário e outros detalhes que não podem ser documentados em texto.

Templates de checklists

Muitos times ágeis criam e usam um templates de checklists em um cartão padrão, para serem replicados sempre que necessário.

Essa checklist é copiada nos cartões usando o recurso "copiar itens de", ao adicionar uma checklist. 

Usar templates de checklists é uma excelente maneira de garantir qualidade e melhoria contínua através da repetição sistemática dos processos.

Assim, à medida que você for melhorando seus templates de checklists ao longo do tempo, automaticamente todos estarão usando as versões mais recentes em seus cartões.

Imagens de capa para um quadro de “Projetos/Objetivos” de alto nível

Alguns times ágeis gostam de dar uma visão geral do trabalho  para pessoas de fora da equipe através das imagens de capa.

Em algumas situações, elas parecem deixar o quadro um pouco complexo, mas também ajudam um quadro de menor volume a se destacar visualmente.

Alguns times fazem mais do que usar quadros de visão geral apenas para relatórios. Eles também usam esses quadros para gerenciar o próximo trabalho do time.

Se você quiser saber mais sobre como fazer isso, veja um template aqui e leia como usar este quadro (ambos em inglês).

Como usar etiquetas sem se complicar

Um erro bastante comum que observo é a criação de etiquetas para qualquer coisa e todos os cartões possíveis.

É uma "tarefa"? Uma "sub tarefa"? Uma "tarefa de interface do usuário"? Uma "melhoria da interface do usuário"? E sabe-se lá o que mais! Mas, afinal, quem se importa com isso?

Às vezes, toda essa complexidade pode ser útil, mas não é uma boa maneira de começar a trabalhar com um quadro Trello para kanban. Nas palavras de John Gall:

“Um sistema complexo que funciona evoluiu, invariavelmente, de um sistema simples que funcionava. Um sistema complexo projetado do zero nunca funciona e não pode ser corrigido para que funcione”.

Então, vamos começar com um sistema simples, com uma a três dessas etiquetas:

1. Bug

2. Bloqueado

3. Urgente (se você achar necessário)

A etiquetas de bug é vermelha para garantir que os bugs se destaquem em seu quadro. Se você não é de um time ágil de desenvolvimento, provavelmente há uma classificação semelhante no seu contexto de trabalho.

Usar uma etiqueta laranja, ao invés de uma lista separada, significa que você pode ver em quais listas os cartões estão ficando bloqueados.

Dessa forma, você pode ver se os cartões bloqueados estão criando um acúmulo de trabalho em uma parte específica do processo.

Esse é um dos motivos pelos quais é bom dividir seu processo em mais do que uma única lista "Em andamento".

A etiqueta Urgente nem sempre é útil, mas, para times que têm tarefas com prazos mais curtos, é bom marcá-las assim.

Isso significa que você pode ver diretamente no quadro quantas solicitações urgentes estão chegando. E a cor da etiqueta é um bom destaque visual que ajuda as pessoas a lembrar que a tarefa precisa ser priorizada.

Dica de Mestre: você pode adicionar etiquetas rapidamente aos cartões passando o mouse sobre eles e pressionando o botão numérico relacionado a essa etiqueta. Por exemplo, a etiqueta vermelha de Bug seria "4", em nosso exemplo.

Como criar subtarefas

Quando você precisa subdividir cartões em subtarefas, existem duas abordagens que parecem funcionar bem para os times:

Use checklists

É aqui que você deve estar quando precisa criar subtarefas para um cartão.

Usando o Markdown, podemos dar instruções bem claras com as  subtarefas.

Para isso, use títulos em negrito e recuo de subtarefas. Se precisar, você pode adicionar várias checklists para detalhar o trabalho.

No entanto, se você se começar a fazer muito isso, talvez seja hora de...

Dividir os cartões quando fizer sentido

Se uma tarefa ficar muito grande, divida o trabalho em dois ou mais cartões separados.

Com o tempo, seu time provavelmente vai perceber o que deixa um cartão "grande demais" e começará a quebrar os cartões em dois ou mais antes mesmo de começar a trabalhar neles.

Os times scrum geralmente acompanham a velocidade, que é uma medida de quantos Story Points (unidades de tempo relativas: a quantidade de esforço necessário para resolver uma tarefa na metodologia scrum) eles completam em média cada Sprint.

Uma regra comum de planejamento de projetos que eles adotam é não criar cartões maiores que metade de sua velocidade para um Sprint.

Essa pode ser uma métrica útil quando um cartão precisa ser dividido. Ou, se você está achando difícil dar claridade sobre o que precisa ser feito no cartão, isso pode ser um bom sinal de que a tarefa deve ser dividida em mais partes.

Configurando seu time para “Épicos”

De modo semelhante à tarefas secundárias, os Épicos (ou missões, ou do que você quiser chamá-los) são um conjunto de cartões com um nível superficial de detalhamento.

Eu já vi três abordagens que funcionam bem, nesse caso:

1. Use etiquetas

Esta é provavelmente a abordagem mais popular. São criadas etiquetas para cada Épico e atribuídas aos cartões.

As etiquetas se movem com os cartões conforme são arrastados pelo ou entre quadros.

Dessa forma, é fácil ver quais cartões pertencem a um Épico e quanto já foi feito em relação ao que ainda precisa ser feito.

Aqui vemos essa abordagem com todas as etiquetas dos Épicos em preto, mas - é claro - você pode optar por usar as cores do jeito que fizer mais sentido para você. 😊

2. Use listas

Outra abordagem é criar uma lista para cada Épico que está programado.

O problema aqui é que você perde o relacionamento com o Épico quando o cartão sai da lista.

Se você trabalha com um ou apenas alguns Épicos por vez, isso não é necessariamente um problema, porque todos sabem quais Épicos estão em andamento no momento.

No entanto, se você tiver muito coisa sendo feita ao mesmo tempo, talvez seja melhor ficar com os marcadores ou...

3. Use o Power-Up do Hello Epics

O mais popular Power-Up de gerenciamento de Épicos que eu conheço é o Power-up do Hello Epics. Ele permite configurar cartões como Épicos e anexar cartões secundários a eles.

Sem dúvidas, vale a pena dar uma olhada nesse power-up se as outras opções não lhe atenderem.

Opções de backlog para lançamento/gestão de produtos

Existem algumas abordagens diferentes para organizar seu backlog. A melhor abordagem para sua equipe é definida, geralmente, pelo tamanho e número de produtos em que você está trabalhando.

A seguir, vou citar os padrões de organização de backlog mais comuns.

Backlog com lista única

Essa abordagem é mais usada por equipes pequenas que trabalham em um único quadro do Trello.

É assim que a maioria costuma começar a organizar seus backlogs. Você tem uma única lista de backlog à esquerda do seu quadro.

Os cartões são priorizados de cima para baixo. Talvez você adicione uma lista "Para priorizar" à esquerda, para que as pessoas possam registrar novos bugs ou sugestões.

Assim, quando tiverem tempo, o responsável pode mover esses cartões para a lista do backlog.

Listas de lançamento ou de marcos

Esta abordagem é mais usada por times ágeis que trabalham em um único quadro do Trello, com um produto em expansão.

Um próximo passo muito comum é adicionar listas que representem os seguintes marcos ou lançamentos:

Aqui temos dois backlogs para dois marcos futuros: "v1" e "v2".

A ideia é que, quando todos os cartões da lista v1 forem concluídos, esse marco (ou lançamento, se preferir) seja concluído.

Essa pode ser uma boa maneira de ajudar as equipes ágeis a gerenciar o escopo, à medida que as coisas evoluem.

Afinal, o que vai fazer a versão 1 ser diferente da versão 2?

Mesmo que manter tudo em um mesmo quadro possa ser benéfico, em algum momento é provável que você mude para um...

Quadro de gestão de produtos

Esse quadro de fluxo de trabalho é mais usado por times maiores que trabalham em vários quadros do Trello ou por equipes com produtos já bem estabelecidos.

Essa abordagem é semelhante às listas de marcos, que vimos acima, mas com todas as listas em seu próprio quadro.

Como este quadro é usado principalmente por gestores ou gerentes de produtos, ele pode ser usado sem seguir regras muito rígidas.

Isso permite que você adicione listas de anotações, de ideias ou de possíveis Épicos, sem perturbar a equipe que deseja manter o quadro principal limpo.

Listas inteiras ou cartões individuais podem ser enviados para os quadros dos times quando estiverem prontos. Isso mantém os quadros principais livres do trabalho de planejamento e pode permitir que um quadro de gerenciamento de produtos alimente vários times.

Power-Ups úteis para turbinar seus quadros do Trello para kanban

Power-Up do Corrello em ação

Neste momento existem mais de 100 Power-Ups para o Trello! Se você não deu uma olhada, vale a pena ver o que temos pronto para você usar com kanban e outras metodologias ágeis.

Aqui estão alguns Power-Ups populares para times ágeis, confira:

• Agile Tools: Story Points, Limites WIP e mais (grátis)

• Corrello: Dashboards para scrum e kanban com Burndowns, CFDs, Ciclo de Tempo e mais

• Hello Epics: Mencionado acima, relacionamentos de tarefas secundários para seus cartões Trello

Acelere seu time ágil

Então, é o que temos para hoje!

Usando as abordagens acima, tenho visto times ágeis de 2-3 membros escalarem rapidamente para mais de 100 pessoas na jornada ágil.

E lembre-se: não é a ferramenta que importa, mas a união do time e a qualidade da entrega!

Leia mais: Guia da metodologia ágil e scrum para iniciantes