Após um tempo considerável trabalhando focado com o método Kanban, tive o prazer de voltar a trabalhar usando Scrum. Praticamente acompanhei um time utilizando esse framework em seu formato by the book, ou seja, na sua íntegra, sem adaptações.

Em uma determinada ocasião, percebi que poderíamos aprimorar as métricas que o time estava utilizando. Nesse momento, ainda não estávamos utilizando o Burndown, um dos gráficos mais famosos para times que utilizam o framework Scrum. Porém, quando começamos a falar sobre ele, lembrei de algo que me incomodava um pouco nesse gráfico: o time só consegue perceber o progresso quando o item de trabalho é concluído e, por consequência, seu valor é debitado no gráfico. Podemos perceber essa situação neste exemplo:

Na imagem acima, o eixo X representa o tempo da Sprint em dias corridos e, no eixo Y, temos o valor de pontos das histórias que fazem parte da Sprint. A barra azul representa a projeção que deveríamos entregar na linha do tempo. Por fim, a linha vermelha é o que efetivamente entregamos e, sempre que ela decresce, significa que um ou mais itens de trabalho foram entregues naquele respectivo dia. Até aqui, nenhuma novidade.

A ideia de criar um novo Burndown

Nesta ocasião, entendi que tínhamos uma oportunidade de aprimorar esse gráfico, testando uma nova forma de acompanhar o progresso do time (no exemplo anterior, a linha vermelha). Validei a seguinte ideia com algumas pessoas: e se a gente considerasse o valor proporcional da evolução do time, de acordo com a etapa em que o item de trabalho está no quadro kanban? Sim, estávamos utilizando o Scrum, mas, por ele ser um framework, agregamos algumas outras práticas, sendo uma delas um quadro para o time gerenciar as etapas de desenvolvimento de todos os itens de trabalho.

A lógica é simples: imagine um item de trabalho (uma história de usuário, por exemplo) de tamanho 8. Essa demanda está dentro de uma Sprint com 29 pontos de história no total. O que aconteceria se a gente debitasse uma proporção deste item de trabalho no Burndown quando ele fosse movido de uma etapa para outra? Na prática, quando começamos a fazer isso em todos os itens de trabalho da Sprint, aconteceu algo semelhante a este exemplo hipotético:

A linha laranja no exemplo acima representa a ideia do Burndown para Scrumban (não achei um nome melhor, então esse ficou autoexplicativo). É possível perceber que ela está mais fluída e decresce de uma forma mais constante se compararmos com a linha vermelha.

Nesta ocasião, nosso quadro kanban era composto por 10 etapas para acompanhar os itens de trabalho, sendo que 7 dessas etapas eram consideradas como WIP (Work In Progress, ou trabalho em progresso). Utilizando novamente o exemplo do item de trabalho com tamanho 8, nós começamos a debitar a proporção deste valor toda vez que o item passava para a etapa seguinte no quadro. Ou seja, o gráfico debitava 1,14 pontos sempre que o item se movesse para a etapa seguinte (8/7, que é igual ao tamanho do item [8] dividido pela quantidade de etapas consideradas como WIP [7]).

Por exemplo: quando o time levou o item (de tamanho 8) da etapa “Em Desenvolvimento” para a etapa “Revisão do Código”, o gráfico (linha laranja) considerou 1,14 pontos entregues. Quando passou de “Revisão do Código” para “Pronto para Testar”, debitou mais 1,14 pontos, e assim sucessivamente até que, quando o item foi levado para “Concluído”, o gráfico debitou os últimos 1,14 pontos, totalizando assim 8 pontos de história concluídos. Esse mesmo raciocício aconteceu para todas as outras demandas: 0,42 (3/7) para itens com tamanho 3, 0,71 (5/7) para itens de tamanho 5, e assim por diante.

Inclusive há um detalhe importante na imagem anterior. É possível perceber que a linha laranja (a que está abaixo da linha reta, a azul) começou com 24,8 pontos, um pouco a menos dos 29,0 pontos do total da Sprint. Isso ocorreu porque, neste exemplo, o time pode ter herdado itens de trabalho não finalizados de uma Sprint anterior e, neste caso, elas já começaram na nova Sprint em uma etapa mais avançada no quadro kanban, como em “Testando”, por exemplo. Logo, elas já tiveram seus pontos debitados e, com isso, a equipe começou a Sprint com uma leve vantagem em determinadas demandas (algumas prontas para serem desenvolvidas, outras já em andamento).

Aprimorando a ideia do Burndown para Scrumban

Porém, havia um problema: considerar a proporção do item pode trazer mais precisão na avaliação do gráfico, como também do progresso do time ao longo da Sprint, mas será que é correto entender que cada etapa do quadro kanban tem o mesmo peso? Em outras palavras, é correto dizer que o tempo alocado para desenvolver (código) um item de trabalho vale o mesmo tanto do que o tempo que ele ficou aguardando para ser testado, por exemplo?

Conversei com algumas pessoas e fiquei convencido de que essa lógica estava equivocada, mesmo trazendo um pouco mais de precisão para a avaliação do gráfico. Solução: começamos a utilizar a proporção do tempo de desenvolvimento em cada etapa do quadro kanban, e, para conseguir esse valor proporcional, extraí o histórico de dados do gráfico Lead time Breakdown e obtive a proporção de tempo em que cada item ficava em cada uma das etapas do quadro kanban. Para obter esse valor, considerei todos os itens de trabalho concluídos em Sprints anteriores e calculei a mediana da amostra de dados. Se você ainda não conhece o Lead time Breakdown, sugiro a leitura da segunda seção do artigo Métricas Ágeis: Cumulative Flow Diagrams e Lead Time Breakdown, escrito por Raphael Albino.

Deixando a explicação acima menos técnica e mais prática: de 100% do tempo que eu demoro para entregar um item de trabalho, quanto tempo ele fica em desenvolvimento? E em testes? E em revisão do código? Foi essa proporção que eu obtive e inseri no gráfico, a fim de deixá-lo mais preciso. O resultado:

Na extração desses dados, por exemplo, descobri que os itens dessa equipe ficavam 48% do tempo em desenvolvimento. Lembra a história de usuário de tamanho 8 da explicação anterior? Então, ao invés de eu debitar no gráfico acima 1,14 pontos quando este item de trabalho passou de “Em desenvolvimento” para “Revisão do Código”, eu debitei 3,84 pontos, pois isso é 48% de 8 pontos. E esse mesmo raciocínio foi aplicado para todas as outras etapas do quadro kanban, bem como para todos os outros itens de trabalho.

Para facilitar a visualização da diferença entre cada um, coloquei, no mesmo gráfico, as três formas que consideram o progresso da Sprint:

Resumindo tudo o que foi falado até aqui através da imagem acima:

• A linha contínua não linear (vermelha) apresenta o que eu estou chamando de Burndown Clássico, ou seja, os débitos dos pontos de história acontecem sempre, e somente quando, um item de trabalho é concluído;
• A linha tracejada (verde) apresenta os débitos de pontos de história por etapa do quadro kanban, considerando que cada etapa teria o mesmo peso (dividindo o total de pontos da história pelo número de etapas consideradas como trabalho em progresso);
• A linha pontilhada (laranja) apresenta o mesmo raciocínio da anterior, porém, ao invés de considerar o mesmo peso para cada etapa no quadro kanban, a análise considera a proporção de tempo em que cada item de trabalho fica nas respectivas etapas consideradas como trabalho em progresso. Como comentei anteriormente, essa proporção de tempo é obtida pelo histórico de itens de trabalho concluídos em Sprints anteriores.

Observação: eu escolhi usar a mediana devido à impossibilidade de utilizar o desvio padrão junto com média, o que poderia causar algumas distorções indesejadas (devido a outliers, por exemplo).

Usando no dia a dia das Sprints

E como usar este Burndown para Scrumban nos seus projetos? Veja esse exemplo:

No dia da imagem, uma hipotética equipe “deveria” ter entregue 10,4 pontos se a Sprint estivesse caminhando em um ritmo igual ao da projeção linear decrescente. Porém, nesse dia, ainda havia 16 pontos abertos na Sprint (baseado no Burndown Clássico). Logo, seria possível dizer que a equipe está atrasada, correto?

Porém, observando o Burndown para Scrumban com proporções, a equipe possuía, neste mesmo dia, apenas 6,2 pontos restantes na Sprint, pois, além dos itens já entregues, ela também está com itens de trabalho em andamento, potencialmente a caminho de ficarem prontos. Por essa ótica, podemos concluir que a equipe está, na verdade, adiantada em relação à Sprint, dado que, neste exemplo, a linha do Burndown para Scrumban está abaixo da projeção linear decrescente.

Em outras palavras, essa equipe hipotética teria:

• Entregue 13 pontos de história (29 pontos estimados para a Sprint, menos 16 pontos restantes);
• 9,8 pontos de história entregues parcialmente (16 pontos restantes menos 6,2 pontos restantes – considerando o Burndown para Scrumban com proporções). Neste caso, o significado da palavra parcialmente pode ser: itens de trabalho testados, mas ainda não publicados, itens desenvolvidos, mas ainda não testados, etc.;
• 6,2 pontos de história remanescentes para serem desenvolvidos em uma ou mais etapas do quadro kanban.

É possível notar também que, no dia anterior ao do exemplo, a equipe também tinha 16 pontos de história restantes (Burndown Clássico), mas, na outra linha (do Burndown para Scrumban com proporções), ela diminuiu de 9,4 para 6,2 pontos. Logo, é possível concluir que o time está avançando com os trabalhos, pois concluiu 3,2 (9,4 menos 6,2) pontos de um dia para o outro, mas ainda não concluiu por completo nenhuma outra demanda.

Ou seja, o time pode usar este gráfico durante a Daily Meeting, por exemplo, sendo um apoio para inspecionar o progresso e, eventualmente, tomar decisões que viabilizem correções no rumo da Sprint.

Conclusão

Você pode entender que considerar itens de trabalho em andamento não seja efetivamente uma entrega de valor, pois cada item tem duas situações: ou ele está concluído e incrementado no produto, ou ainda está em andamento. E eu concordo com você! Entretanto, a ideia do Burndown para Scrumban é deixar o acompanhamento do dia a dia mais preciso, visto que ele também considera os itens em andamento. O objetivo não é substituir o Burndown Clássico (por isso eu deixei as duas linhas no mesmo gráfico, pois cada uma delas oferece uma informação distinta e complementar).

E você, o que achou desta proposta de Burndown para Scrumban? Estou totalmente aberto a debater a ideia, bem como ajudar seu time a utilizar esse novo gráfico.