Burndown gera o mesmo sentimento de uma barra de download

Eu considero o gráfico de tendência utilizado por equipes SCRUM conhecido como Burndown Chart tão necessário quanto uma barra de progresso durante um download. Nem todas as equipes pensam assim, mas deveria ser angustiante não ter uma percepção clara e explícita a qualquer um sobre o quanto falta fazer e se cabe no tempo disponível …

Algumas equipes não tem, ou pior, tem mas não dão valor ao quadro de burndown. A verdade é que nenhum quadro de tarefas oferece a percepção cristalina que um Burndown bem feito nos dá quanto a tendência de sucesso ou não. Se informarmos o tempo faltante re-estimado pela equipe, o burndown permite ver a tendência de concluir tudo até o dia previsto de entrega ou não.

Construir um burndown por história só faz sentido se suas histórias são todas pequenas, de uma granularidade homogênea. Contruí-las por tarefa é um pouco melhor, seguindo a mesma premissa, com tarefas pequenas e homogêneas. Se tem-se o hábito de estimar em horas, o burndown é tão preciso quanto a técnica e artefato permitem.

A granularidade e unidade de estimativa gera burndowns meio inúteis como os dois abaixo a esquerda ou o da direita que nos dá uma tendência real e precisa a cada dia do nosso sprint. A maior parte das equipes possuem ainda dificuldade em quebrar histórias em tamanho adequado, tanto quanto na quebra de tarefas, outro empecilho são softwares utilizados, gerando burndowns úteis ou inúteis.

Outra maluquice que na teoria se sustenta e na minha prática não é gerar um único burndown para a equipe, somando os tempos ou unidades sem diferenciar alocações de desenvolvimento, testes, analistas, como se todos já fossem multi-disciplinares. Este hábito pode ocultar tempo estourado de desenvolvimento e sobrando em testes ou desequilíbrios piores ainda caso tenha outras divisões.

Em 30 anos em desenvolvimento de software não tive experiências de plena multi-disciplinaridade, pelo contrário, analistas, desenvolvedores e testadoras ainda são uma realidade por opção racional da maioria das empresas. Fechar os olhos para isso e somar tudo em uma única linha de burndown é ingênuo ou eu ainda não entendi para que serve o Burndown.

Finalmente, minha abordagem é simples demais, ter um Burndown não conclusivo é um grande desperdício. Ele só tem valor real se qualquer integrante puder “lê-lo” e tirar todas as conclusões por si, se precisa de uma manual e alguém experiente que cruze dados e chegue a conclusões baseados em sua experiência é sinal inequívoco de que está tudo muito errado.

Não existe quadro Kanban que nos mostre facilmente o que o Burndown oferece, no quadro é possível ver gargalos, ocorrências, fluxo, mas não pode nos dar tendência de sucesso cruzando o quanto falta versus o tempo que ainda temos até o final do Sprint.

Eu acredito em estimativas como uma fonte de auto-conhecimento, até concordo que empresas que possuam equipes de alta senhoridade e muita experiência em metodologias ágeis possam abdicar de estimar e basear-se apenas no sentimento do quanto conseguem fazer e fazem, mas decididamente não é o meu caso.

Não sou xiita, se a cultura da empresa e seus protagonistas preferem trabalhar só com pontos ou nem isso, Ok, mas não é o que recomendo e não reflete o sucesso que tive em implantações difíceis com equipes que estavam adotando SCRUM e iniciando uma trajetória ágil em empresas que necessitavam métricas inteligíveis.