Como medir os resultados do Kanban?

Sempre que falamos da utilização da metodologia Kanban em projetos, uma das primeiras dúvidas que surge é sobre como metrificar os resultados da equipe em relação às atividades ao longo do projeto.

Por ser uma metodologia de desenvolvimento ágil menos prescrita, onde o fluxo de demandas é “puxado” de acordo com a necessidade do time, algumas pessoas acreditam que o Kanban não trabalha com prazos e por isso, ficam em dúvida entre qual método adotar no projeto. Mas não é bem assim que as coisas funcionam.

O Kanban possui várias recomendações e é considerado uma metodologia muito efetiva, se praticada da forma correta. Como abordado no artigo “Kanban no desenvolvimento de software: origem e conceitos”, não basta ter um board dividido em colunas, com alguns cards distribuídos para realmente trabalhar com este método.

Além dos pontos citados no artigo que mencionei acima, o Kanban tem uma outra vantagem: todos os resultados que metrificamos são baseados em um histórico e não em estimativas ou achismos, algo que nos dá uma grande vantagem.

Mas, chega de falar dos benefícios e vamos ao que realmente interessa.

Como medir os resultados do Kanban?

O primeiro passo para conseguir medir os resultados, é ter um workflow bem definido. Isso significa que você deve mapear muito bem as fases do seu processo de desenvolvimento, desde o momento em que a demanda é concebida, passando pelo desenvolvimento em si e chegando até a entrega efetiva para o cliente.

É claro que devemos sempre considerar que o Kanban é um processo evolutivo. Então, não faça mais do que você precisa, comece pelo simples: primeiro crie o board com um processo básico e depois vá adicionando as fases que fazem sentido.

Com o processo rodando bem, você deve evoluir para começar a medir os resultados e, neste momento, é importante ter tudo bem detalhado. Uma dica é utilizar o esquema de colunas de espera e de ação, onde você tem, por exemplo, uma coluna “Aguardando teste” e uma seguinte sendo “Em teste”. Assim, você consegue medir o tempo em que a tarefa levou para ser testada e o tempo em que ela ficou na fila de espera.

Na maioria das vezes, a tarefa leva mais tempo “esperando” do que sendo executada e é a partir deste ponto que você começa a identificar os gargalos no processo.

Medindo os resultados através do Throughput

A primeira métrica que vamos abordar é o throughput que, apesar do nome complicado, é bem simples de entender.

Basicamente, o throughput mede a capacidade de entrega dos times ao longo de um ciclo, por exemplo, quantas demandas seu time consegue entregar no período de uma semana?

Com isso, você pode perceber a frequência das entregas e a “capacidade” do seu time. Se pensarmos em um cenário onde a equipe trabalha com histórias de usuário com tamanho e complexidade parecidos, é possível ter previsibilidade de quando uma feature será entregue.

Uma forma muito boa de se quebrar tarefas é utilizando a Matriz de complexidade e incerteza. Se você ainda não conhece nada sobre o assunto, recomendo que dê uma olhada no artigo Requisitos em equipes ágeis: Falando sobre complexidade e incerteza, do Raphael Albino.

Nesse gráfico, podemos observar que a equipe não está tendo uma tendência nas entregas e seria um pouco difícil dar previsibilidade para o cliente dessa forma.

Um segundo item interessante deste gráfico é a categorização de atividades. Como é possível observar, existe uma separação entre “Story” e “Bugs“.

Categorizando atividades

Uma prática muito boa também para medir os resultados do Kanban, é sempre categorizar as atividades. Assim, é possível perceber onde o esforço da equipe está sendo investido. 

A categorização é importante já que o time pode estar entregando dez atividades por semana, mas se oito forem bugs, com certeza o cliente não enxergará muito valor nessas entregas. Nesse caso, é necessário fazer um alinhamento de expectativas e entender o motivo por trás de tantos bugs.

Entendendo o Lead Time

A terceira estratégia que pode ajudar bastante no entendimento do que está acontecendo no projeto, e na tomada de decisões é o lead time.

Assim como o throughput, o lead time também é uma métrica bem simples. Ele contabiliza o tempo total que leva para uma tarefa fica pronta, desde o momento em que ela entrou na fila de desenvolvimento “To do”, até o momento em que ela é entregue e chega até a coluna “Done”.

Como medir os resultados com Lead Time e Lead Time Breakdown

Além do lead time, existe o lead time breakdown. Nele podemos visualizar o tempo total para tarefa ficar pronta e quanto tempo ela ficou em cada fase.

Por isso, é importante termos a separação das colunas de espera e de ação. Imagine por exemplo que uma demanda ficou 15 dias na coluna “Ready to homolog“, aguardando a homologação do cliente, e depois apenas 2 dias na coluna “In Homolog“. Ou seja, seu cliente levou duas semanas para homologar um item que ele pode validar em apenas 2 dias. 

Dei esse exemplo, pois isso já aconteceu em projetos que gerenciei. E foi através do gráfico de lead time breakdown que mostrei ao cliente, que os atrasos dos quais ele questionava, estavam sendo causados pela demora dele em uma fase do processo que dependia dele. 

Este gráfico particularmente é um dos meus preferidos, pois é simples de entender e pode dar muitas informações. No eixo X temos os itens de trabalho, e no eixo Y os dias que levaram para serem feitos. 

Além disso, podemos observar quanto tempo o item ficou em cada fase do processo. O número 0 nas colunas, significa que o item não ficou nenhum dia naquela fase.

Neste exemplo podemos observar que existe um gap imenso na fase de Deploy. Isso pode ser causado por falta de um processo bem definido de publicação, ou burocracia interna. O ideal seria um processo de deploy automático, mas sabemos que no dia a dia nem sempre é assim.

Dessa forma, seria o caso de acionar algum responsável na empresa que pudesse resolver isso, para agilizar a liberação de novas funcionalidades em produção.

Tem muito mais para medir os resultados do Kanban…

Essas métricas são apenas algumas de todas as que podemos utilizar no nosso dia a dia e, se você nunca utilizou nada parecido, sugiro que comece por elas. Além das que foram listadas neste conteúdo, há também o Burn Down, muito utilizado com o Scrum, o Burn Up, CFD, gráfico de eficiência do fluxo, entre outras maneiras de medir os resultados do Kanban.

De qualquer forma, mesmo que você comece pelo básico, posso garantir que isso já fará toda a diferença, tanto no relacionamento com sua equipe, quanto no alinhamento de expectativas com o cliente.

Ah, e se precisar de uma ajuda para entender melhor como você pode implementar a metodologia em sua empresa, nos Insights da Kodus você encontra diversos artigos sobre Kanban e outras metodologias ágeis de desenvolvimento de software.