O Burndown chart ou gráfico de Burndown é o gráfico utilizado pelas equipes Scrum para representar diariamente o progresso do trabalho em desenvolvimento. Ou seja, após cada dia de trabalho o gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho total planejado.

É comum a Equipe de Desenvolvimento usar esse gráfico ao longo da Sprint, para medir os pontos das histórias finalizadas ao longo dos dias da Sprint e ter uma visibilidade do seu ritmo de trabalho, verificando se o ritmo está adequado para atingir a meta da sprint, cumprindo com o que foi planejado.

O Burndown é o gráfico mais simples que há no Scrum e que muitas equipes nem sempre dão o devido valor as informações referente ao processo de trabalho que ele apresenta, indiretamente.

Simplesmente traçar o gráfico pelo simples fato de traça-lo é desperdício, o importante é identificar nele o que há de errado com a estratégia, o processo de trabalho, adotado pela Equipe Scrum. E quando digo Equipe Scrum, é pelo fato de que embora ele represente porção de trabalho desenvolvido, que é de responsabilidade direta da equipe, todos estão comprometidos e ligados ao resultado final que o grafico apresentará: Equipe de Desenvolvimento, Scrum Master e PO.

O fato de uma equipe não finalizar as histórias ao final da sprint pode ser não por falta de comprometimento da equipe de desenvolvimento, mas pela indisponibilidade do PO em ajudar a equipe no momento que ela mais precisa, ou do Scrum Master que não resolve em tempo os impedimentos que surgem em uma sprint.

Nesse post vou explicar como montar e traçar o gráfico Burndown ao longo da sprint, para aqueles que estão iniciando no Scrum e apresentarem alguns dos indicativos que ele nos mostra para avaliarmos nas reuniões diárias e também após a sprint na reunião de retrospectiva do projeto.

O gráfico Burndown marca:

    • no eixo horizontal os dias da sprint, do 1o dia ao último e
    • no eixo vertical os pontos que foram planejados para compor a sprint, partindo do máximo de pontos da sprint (velocidade da equipe) até zero.

O intervalo de pontos será definido pela equipe. Nos exemplos apresentados nesse post todos os gráficos possuem como intervalo 5 pontos.

Desenhado os eixos do gráfico com os dias da sprint e os pontos da sprint de 5 em 5 pontos, vamos para a segunda etapa que é a marcação da 1a linha do gráfico.

A 1a linha do gráfico é traçada como uma diagonal que tem início no ponto máximo até o ponto zero do eixo vertical, e do 1o dia da sprint até o último dia da sprint. Nos gráficos apresentados nesse post essa diagonal está representada pela linha vermelha.

Essa linha diagonal serve de guia para mostrar se a equipe está atrasada ou adiantada no desenvolvimento de seu trabalho. Quando a equipe está atrasada no desenvolvimento a linha azul, correspondente ao andamento dos trabalhos, estará a direita da linha vermelha e quando a equipe estiver adiantada nos trabalhos a linha azul estará a esquerda da linha vermelha.

Com essa simples informação já é possível visualizar ao longo da sprint se a equipe está adotando uma estratégia para chegar ao final com todas as histórias meio prontas, como todas as histórias prontas, ou com pelo menos algumas prontas.

Vamos analisar o caso de estudo apresentado a seguir:

    • Sprint com timebox de 1 semana de duração, ou seja, 5 dias úteis de trabalho.
    • Sprint Backlog está composto por 8 histórias com as seguintes pontuações e na ordem de implementação definida pelo PO:
      •  História 1 – 5 pontos
      • História 2 – 2 pontos
      • História 3 – 13 pontos
      • História 4 – 2 pontos
      • História 5 – 8 pontos
      • História 6 – 20 pontos
      • História 7 – 8 pontos
      • História 8 – 2 pontos 

Total = 60 pontos.

O gráfico que teremos no início do projeto pode ser observado no 1o gráfico apresentadado abaixo. Ele possui apenas a linha diagonal partindo da soma total de pontos das histórias da sprint (60 pontos) e do 1o dia da sprint até zerar a pontuação, chegando ao último dia da sprint com todas as histórias implementadas.

               

Após o primeiro dia de trabalho, em cada reunião diária, a equipe calcula o total de pontos das histórias concluídas para descer a reta azul no gráfico.

E como é feita essa conta? A equipe levanta as histórias que foram finalizadas e subtrai do total de pontos o somatório de pontos das histórias finalizadas.

No 2o gráfico, apresentado acima, temos o seguinte:

    • No 1o dia de trabalho a equipe finalizou 5 pontos, logo do 1o dia para o 2o traçamos a reta diminuindo 5 pontos do total de 60 pontos da sprint.
    • No 2o dia de trabalho a equipe finalizou 25 pontos, como podemos observar, que representam (dado o caso de estudo em análise) as histórias, 2, 3, 4 e 5.
    • No 3o dia de trabalho a equipe não finalizou nenhuma história, portanto a linha azul é traçada na horizontal, mantendo os 30 pontos que ainda restam serem implementados na sprint.

Resta ainda dois dias de trabalhos para equipe finalizar 30 pontos referentes as histórias 6, 7 e 8, com 20, 8 e 2 pontos, respectivamente. Como falei anteriormente tudo vai depender da estratégia que a equipe irá adotar. Nas reuniões diárias a equipe deve avaliar a melhor tática a seguir para chegar ao final com todas as histórias prontas. Pois ao contrário a equipe pode chegar ao final com algumas prontas e outras não ou com todas histórias as restantes meio prontas. Vamos analisar os três casos:

No 1o caso apresentado abaixo a equipe chega ao final da sprint sem finalizar as últimas 3 histórias. Possíveis cenários que podemos levantar para esse caso:

    • as 3 histórias foram iniciadas, mas nenhuma foi finalizada, ou seja, 3 histórias meio prontas.
    • apenas a história 6, de 20 pontos, foi iniciada e as demais nem foram tocadas. Ou seja, duas histórias não iniciadas e uma meio pronta.

Possíveis causas para explicar os cenários levantados acima:

    1. A equipe não traçou bem sua estratégia de ataque as histórias para chegar ao final com o máximo de histórias prontas.
    2. A equipe pode ter focado em finalizar a história 6, de 20 pontos, seguindo a prioridade do que era de mais valor para o PO, mas no entanto a história pode ter sido subestimada. Ou seja, não é uma história de 20 pontos, mas algo maior. Se essa causa levantada for verdadeira isso pode indicar que histórias com 20 pontos de estimativa, para essa equipe, sejam histórias que precisam ser mais detalhadas e quebras em duas ou mais histórias menores.
    3. Sugiram diversos impedimentos que o Scrum Master não foi capaz de resolvê-los em tempo de não afetar a equipe e consequentemente a sprint.
    4. A história de 20 pontos precisava de mais detalhes e o PO não estava acessível para esclarecer dúvidas da equipe em tempo do término do prazo da sprint.

Vários outros pontos podem ser levantados. Cada equipe deverá analisar seu caso particular na reunião de retrospectiva e chegar a causa do problema para consequentemtente dar uma solução para o problema, evitando que esse cenário se repita nas próximas sprints.

No 2o caso apresentado abaixo a equipe chega ao final da sprint com mais 10 pontos finalizados. Esses pontos, para o caso de estudo em análise, são referentes as histórias 7 e 8, de 8 e 2 pontos respectivamente. Possíveis causas podem explicar esse cenário:

    1. A equipe no 4o dia de trabalho achou por bem adotar a estratégia de interromper o trabalho da história 6 e concentrar os esforços nas outras, para chegar ao final com o máximo de histórias prontas. Mesmo fugindo a ordem.
    2. A equipe insistiu mais um dia trabalhando na história de 20 pontos e no 5o dia que resolveram interromper e atacar as outras duas histórias, que para felicidade de todos foram iniciadas e finalizada em um dia.
    3. A equipe desde o 3o dia de trabalho já estava trabalhando nas duas últimas histórias e a história 6 nem foi tocada. Ou seja a equipe finalizou 30 pontos em dois dias e nos 3 dias seguintes finalizou apenas 10 pontos. Possivelmente há problemas de estiamtivas nas histórias que devem ser discutidos na retrospectiva e acertados para a próxima sprint.

O 3o caso é o cenário onde a equipe chega ao final com tudo pronto. O que foi planejado foi entregue. Mas ainda assim cabe uma reflexão para esse cenário, pois o que está bom também pode ser melhorado. Vamos a alguns pontos:

    • A equipe tem plena noção de sua velocidade, ou seja, o planejado é realmente o que a equipe consegue se compromenter em entregar.
    • Para essa equipe histórias com 20 pontos de estimativa não representam riscos para a sprint. São histórias grandes, mas que estão em um nível de detalhe suficiente para a equipe seguir com o trabalho sem grandes ameaçãs a sprint.
    • Um dia sem finalizar história pode ter sido por conta de impedimentos, mas impedimentos que o Scrum Master conseguiu removê-los em tempo de não impactar o término da sprint.
    • Por outro lado… um dia sem finalizar história pode ter sido por conta da equipe ter se disperçado em outras atividades que não pertence a sprint, nesse caso a equipe tem uma velocidade de produção maior que 60 pontos, mas que são empregados em atividades fora da sprint. É preciso analisar esse caso.
    • Por outro lado, também… um dia sem finalizar história alguma pode ter sido por conta da equipe ter tido a necessidade de ter mais esclarecimentos do PO para uma certa história, mas o PO não estava acessível. Novamente a equipe pode ter uma velocidade de produção maior que 60 pontos, mas que não são alcançados pelo relacionamento do PO com o projeto. É preciso também analisar esse caso em busca de melhoria.

Resumindo, o burndown é muito mais do que um simples gráfico que ao longo da sprint decresce o total de pontos da sprint indicando apenas o trabalho que resta a ser implemetado no total de dias restantes da sprint.

Ele fornece indicativos que todos da equipe Scrum (PO, SM e equipe de desenvolvimento) devem estar atentos para melhorar a cada sprint o ritmo de produção e assim trabalhar de forma ágil, como a metodologia nos provê.

Observação: Clique nos gráficos para vê-los ampliados