O gráfico de burndown é considerado um dos mais úteis para monitorar o progresso de um time ágil. O gráfico representa a quantidade de trabalho que falta ser feito no eixo vertical (y) versus o tempo no eixo horizontal (x).
A unidade de tempo do eixo Y pode ser em dias, horas, semana ou sprints, no caso de um release burndown, e a unidade da quantidade do eixo X pode ser em horas de trabalho ou pontos. É importante mencionar que a unidade escolhida deve ser a mais adequada com a realidade de cada projeto ou empresa, visto que cada unidade possui visões e objetivos diferentes conforme citado por Alexandre Magno na lista do Scrum Brasil:
"burndown por horas e burndown por pontos tem propósitos diferentes!! Ninguém espera que um burndown por horas diga o quando de valor foi entregue, mas apenas o acompanhamento do ritmo dirário do time. Os dois são importantes!"
O burndown revela dados importantes sobre o time como: o seu andamento e o que pode ser melhorado. Algumas empresas o utilizam para acompanhar a produtividade ou como ferramenta de coleta de dados para as retrospectivas, e principalmente indica como o time está evoluindo, através do seu acompanhamento a cada iteração.
Recentemente Hiren Doshi e Kane Mar publicaram artigos sobre a análise do burndown, apresentando exemplos de gráficos e que tipo de informações ou perguntas podemos extrair.
A exemplificação de Hiren Doshi foi baseada nas perguntas e no gráfico abaixo:
- Quão bom é esse time no planejamento?
- O time é realmente auto-organizado e está trabalhando como uma equipe?
- Quais melhorias esse time pode fazer?
- O quão bem o time está executando as histórias planejadas no Sprint?
A Linha 1 (Azul) nunca atinge o zero, o que indica que o planejamento e execução do time não estão bons, existindo vários motivos, como alteração de prioridade durante o sprint, planejamento de mais histórias do que a capacidade ou até mesmo uma falta de união no time. Além disso, indica que é necessário melhorar o planejamento.
A Linha 2 (Roxa) atingiu a meta, mas esteve longe da linha ideal e no meio uma curva acentuada o que pode indicar que o time não atualizou suas estimativas corretamente ou histórias incompletas foram retiradas do sprint.
A Linha 3 indica que o planejamento e execução foram bons. O time é auto-organizado, diz se a meta foi atingida da mesma forma nos últimos sprints e não deixa claro melhorias, mas sempre existem melhorias no planejamento.
Da mesma maneira, Kane Mar separou o burndown em sete categorias:
- Fakey- Fakey: O andamento do gráfico é igual a linha ideal. A maioria dos sistemas possui alguma complexidade, portanto, deve existir alguma descoberta durante a execução. Esses gráficos são comuns em times que trabalham em um ambiente com comando e controle.
- Late-Learner: Esse gráfico possui uma linha crescente e uma curva decrescente no final do sprint. É comum para times novos de Scrum que estão aprendendo a metodologia e como se comunicar de forma efetiva. Geralmente a curva indica a percepção tardia que o teste é uma parte importante da entrega do software.
- Middle-Learner: A curva decrescente é apresentanda no meio do sprint, demonstrando mais maturidade do time, especialmente na definição antecipada do que deve ser testado.
- Early-Learner: Times que apresentam progresso, possuem a curva decrescente no inicio do sprint, seguida de uma linha decrescente gradual. Nesse caso, o time aprendeu a importância de descobertas antecipadas, permitindo que trabalhem de forma mais eficaz.
- Plateau: Times que possuem uma fase inicial de progresso e não conseguem mantê-lo durante o sprint, possuem um curva decrescente seguida de um linha reta.
- Never-Never: Times que trabalham bem até um evento inesperado ocorrer no final do sprint, apresentam uma linha decrescente estável e no final do sprint uma curva crescente. A curva pode ocorrer porque o time esclareceu algo muito tarde ou o Product Onwer mudou o escopo, dificultando ou impossibilitando atingir as metas. Essas mudanças tardias devem ser levantadas e resolvidas na retrospectiva.
- Scope-increase: Esse gráfico possui um pico repentino na linha de trabalho restante, sendo comum em times que não analisam o escopo do trabalho necessário corretamente. Existem várias abordagem para esse tipo de problema, como negociar com o product owner ou até mesmo interromper o sprint.
Um artigo publicado no site da LocalWeb também apresenta outra análise do gráfico voltada para as possíveis mudanças no sprint, incluindo análises conjuntas com o gráfico de BurnUp e indicação do que deve ser feito ou não. Além desses artigos podemos encontrar diversos outros artigos sobre a análise do burn-down como o artigo Feel the burn – Getting the most out of burndowns charts do George Dinwiddie ou Earned-value and burn charts do Alistar CockBurn.
Concluindo, o gráfico burndown é uma ferramenta importante para o acompanhamento do progresso de um time ágil e muitas informações podem ser extraídas do mesmo. Também podemos utilizá-lo para acompanhamento do projeto, produto ou releases.
E para você leitor? Qual o uso e a importância dos gráficos de BurnDown?