Burndown Chart: O que É e Como Ler Um

Um Burndown chart é o sinal mais útil que uma equipe Scrum pode observar a cada manhã. Em um único olhar, ele mostra se o Sprint está no ritmo certo, atrasando ou acumulando escopo silenciosamente sem que ninguém tenha planejado.

Dados relevantes

• Os Burndown charts surgiram com o artigo de Ken Schwaber de 2000 que apresentou o gerenciamento de processos Scrum e têm sido o artefato Scrum mais utilizado desde então (Scrum Alliance, 2023).
• Equipes que atualizam o Burndown diariamente relatam 17% melhor cumprimento de metas de Sprint do que equipes que atualizam semanalmente (State of Agile Report 17th edition, 2024).
• A linha "ideal" do Burndown assume progresso diário uniforme, mas Sprints reais mostram uma curva J com entregas concentradas no final em cerca de 60% dos casos (pesquisa da comunidade Atlassian, 2023).

O que é um Burndown chart?

Um Burndown chart é um gráfico que acompanha quanto trabalho resta em um Sprint ou projeto ao longo do tempo, com o objetivo de chegar a zero até o prazo. O eixo horizontal representa o tempo (dias, Sprints ou semanas) e o eixo vertical representa o trabalho restante (Story Points, horas ou tarefas). À medida que a equipe conclui o trabalho, a linha "queima" em direção a zero.

Os Burndown charts pertencem ao kit de ferramentas do Scrum, embora equipes que usam outras metodologias ágeis também os adotem. O principal atrativo é a simplicidade: não é necessário interpretar dezenas de métricas para entender o progresso da equipe. Duas linhas contam toda a história.

O gráfico é distinto de um gráfico Gantt, que mapeia tarefas para datas, ou de um gráfico PERT, que foca nas dependências entre tarefas. Um Burndown chart não se preocupa com tarefas individuais. Faz apenas uma pergunta: quanto trabalho resta e esse número está diminuindo rápido o suficiente?

Como funciona um Burndown chart (as duas linhas)

Todo Burndown chart tem duas linhas:

A linha ideal (também chamada de linha de referência ou guia) corre como uma diagonal reta do canto superior esquerdo ao canto inferior direito. Começa no comprometimento total do Sprint (digamos, 80 Story Points no Dia 0) e termina em zero no último dia. Essa linha pressupõe que a equipe conclui o trabalho a uma taxa perfeitamente uniforme a cada dia. Ninguém espera que isso aconteça de fato. A linha ideal existe como ponto de referência, não como previsão.

A linha real traça o trabalho restante real conforme é registrado a cada dia. É atualizada no standup diário ou ao final de cada dia útil. Quando essa linha está acima da linha ideal, a equipe está atrasada. Quando está abaixo, a equipe está adiantada. Quando fica plana (sem movimento descendente), o trabalho não está sendo concluído ou não está sendo registrado. Quando sobe, novo escopo foi adicionado ao Sprint.

Os eixos:

• Eixo X: Dias do Sprint, numerados de 0 (ou 1) até o último dia
• Eixo Y: Trabalho restante, medido em Story Points ou horas

O valor inicial no eixo Y equivale ao comprometimento total do Sprint. Zero no eixo Y significa que o Sprint está concluído.

Burndown de Sprint vs Burndown de release

As equipes utilizam duas variantes principais. Elas respondem a perguntas diferentes e atendem a públicos distintos.

A maioria das equipes começa com Burndowns de Sprint. Os Burndowns de release passam a ser valiosos quando a equipe tem histórico suficiente de Sprints para projetar uma Velocity confiável. Ambos ficam ao lado de ferramentas como a estrutura analítica do projeto e os documentos de planejamento do ciclo de vida do projeto.

Como ler um Burndown chart (4 padrões comuns)

Aprender a ler um Burndown chart significa reconhecer quatro formas recorrentes. Cada uma conta uma história diferente sobre a saúde do Sprint.

Padrão 1: Acompanhando o ideal

A linha real permanece próxima da linha ideal, desviando levemente acima ou abaixo, mas nunca se afastando muito. É assim que parece uma execução saudável de Sprint. Não significa que tudo está perfeito. Significa que os impedimentos estão sendo resolvidos rapidamente e que a equipe estimou de forma razoável.

Padrão 2: Atrasado em relação ao cronograma

A linha real corre consistentemente acima da linha ideal. A lacuna entre as duas linhas cresce à medida que os dias passam. No Dia 5 de um Sprint de 10 dias, a equipe pode ter concluído apenas 20% do trabalho quando se esperava 50%. Esse padrão exige uma conversa imediata no standup diário. Causas comuns: histórias foram subestimadas, membros da equipe estão bloqueados ou o Sprint foi sobrecarregado desde o início.

Padrão 3: Adiantado em relação ao cronograma

A linha real cai abaixo da linha ideal e se mantém lá. A equipe está concluindo trabalho mais rápido do que o planejado. Parece bom, mas vale a pena perguntar por quê. Ou as histórias foram superestimadas (o que infla as métricas de Velocity), ou a equipe está cortando atalhos na qualidade. Se a estimativa foi simplesmente conservadora, a equipe pode puxar histórias do Backlog para manter o ritmo.

Padrão 4: Expansão de escopo

A linha real sobe abruptamente no meio do Sprint em vez de continuar descendo. Esse pico significa que novo trabalho foi adicionado ao Sprint após o início. Um pequeno salto pode ser aceitável para correções críticas. Um pico grande ou repetido sinaliza planejamento de Sprint deficiente ou pressão para aceitar solicitações no meio do Sprint sem negociação. Compare isso com os princípios do Scrum vs Kanban: o Kanban explicitamente permite mudanças de fluxo no meio do ciclo, enquanto o Scrum visa à estabilidade do Sprint.

Como criar um Burndown chart: passo a passo

Passo 1: Colete os dados do Sprint

Antes de mexer em qualquer gráfico, colete dois números: o total de Story Points (ou horas) comprometidos no Sprint e o número de dias úteis do Sprint. Esses definem seu ponto de partida e seu ponto de chegada. Documente ambos nas notas de planejamento do Sprint.

Passo 2: Configure os eixos

Desenhe ou configure o gráfico com dias no eixo X (do 0 até o último dia) e trabalho restante no eixo Y (de 0 até o comprometimento total). Identifique ambos os eixos claramente. Se estiver construindo em uma planilha, congele a linha de cabeçalho e a coluna de dias para que fiquem visíveis conforme o Sprint avança.

Passo 3: Trace a linha ideal

Conecte dois pontos: (Dia 0, comprometimento total) e (último dia, 0). Essa linha reta é sua referência. Em uma planilha, uma fórmula simples de SLOPE resolve isso. No Jira ou Azure DevOps, a ferramenta a desenha automaticamente quando você define as datas do Sprint e os totais de Story Points.

Passo 4: Trace o trabalho real diariamente

Ao final de cada dia útil (ou durante o standup), registre os Story Points restantes. "Restantes" significa a soma dos Story Points de todas as histórias incompletas. Não subtraia crédito parcial para histórias em andamento. Uma história está concluída ou não está. Essa regra binária mantém o gráfico honesto e evita sinais falsos de progresso.

Passo 5: Interprete e aja

Não apenas atualize o gráfico e siga em frente. Cada ponto de dados do dia é um estímulo para uma conversa. A linha real está acima do ideal? O que está bloqueando a equipe? Uma história está demorando mais do que o estimado? Essas histórias precisam ser divididas em partes menores? O Burndown chart é mais útil quando impulsiona ações específicas, não apenas relatórios.

Exemplos de Burndown chart por equipe

Equipes diferentes usam Burndown charts de formas levemente distintas. A mecânica central é a mesma. A duração do Sprint, a escala de Story Points e a cadência de atualização variam com base no tamanho da equipe e no fluxo de trabalho.

Equipes de engenharia frequentemente veem o padrão de curva J: queima lenta na primeira metade, depois conclusão rápida na segunda metade, conforme o trabalho de integração e revisão converge. Equipes de marketing tendem a ver linhas planas no meio do Sprint, pois o trabalho se acumula aguardando aprovação. Equipes de design acompanham mais de perto o ideal quando as cerimônias do Sprint são respeitadas, mas sofrem mais com expansão de escopo quando as revisões das partes interessadas chegam tarde.

Burndown vs Burnup chart

Os gráficos Burndown e Burnup são parentes próximos, mas respondem a perguntas levemente diferentes.

Um Burndown chart acompanha o trabalho restante. A linha vai do alto para zero. O foco é no que resta.

Um Burnup chart acompanha o trabalho concluído. A linha sobe de zero para cima. Uma segunda linha mostra o escopo total. A lacuna entre as duas mostra quanto trabalho ainda resta.

A principal vantagem do Burnup chart é a transparência em relação a mudanças de escopo. Quando novas histórias são adicionadas, a linha de escopo total sobe, e todos podem ver tanto o trabalho adicionado quanto o progresso no comprometimento original. Em um Burndown chart, as adições de escopo aparecem como picos ascendentes, que podem ser mais difíceis de interpretar rapidamente.

A maioria das equipes Scrum começa com Burndown charts por serem mais simples. Equipes com mudanças frequentes de escopo frequentemente migram para Burnup charts porque separam a pergunta "quanto fizemos?" da pergunta "quanto foi adicionado ao nosso trabalho?". Algumas equipes exibem ambos lado a lado durante as revisões de Sprint.

Erros comuns (e como corrigi-los)

Melhores práticas

• Atualize o gráfico no mesmo horário todos os dias. Os standups matutinos funcionam bem porque a equipe discute impedimentos logo após a atualização. A consistência importa mais do que o momento perfeito.
• Mantenha a linha ideal sempre visível. Não a oculte quando a linha real se afastar. O desvio é o ponto.
• Exiba o gráfico onde a equipe possa vê-lo. Um painel compartilhado ou uma tela no espaço físico da equipe mantém o status do Sprint em evidência sem exigir esforço extra para verificar.
• Não adicione histórias a um Sprint sem ajustar o comprometimento total. Se novo trabalho entrar no Sprint, o ponto inicial do eixo Y deve refletir o novo total. Caso contrário, o gráfico subestima o trabalho restante.
• Use o gráfico em retrospectivas, não apenas nos standups. O formato do Burndown final é um rico estímulo para retrospectiva. Um padrão persistente de plano-depois-acentuado pode sinalizar que as cerimônias do Sprint precisam melhorar ou que as histórias são grandes demais.
• Combine com um gráfico de Velocity ao longo do tempo. O Burndown de um único Sprint mostra a saúde atual. A Velocity em 5 a 6 Sprints revela se a equipe está melhorando, estagnando ou declinando.
• Mantenha a granularidade das histórias consistente. Histórias maiores do que 8 Story Points raramente queimam de forma suave. Divida-as. Histórias grandes criam uma planura artificial no gráfico até que de repente estejam "concluídas" de uma vez.
• Não use o Burndown chart para avaliar o desempenho individual. Ele reflete o progresso em nível de equipe. Usá-lo para identificar indivíduos que "não estão contribuindo" interpreta mal os dados e prejudica a confiança.

Perguntas frequentes

O que significa uma linha plana em um Burndown chart?

Uma linha plana significa que nenhum trabalho foi concluído durante aquele período, pelo menos de acordo com o que foi registrado. As causas mais comuns são: histórias não estão sendo fechadas no sistema de acompanhamento mesmo que o trabalho esteja concluído, a equipe está bloqueada por uma dependência ou dado ausente, ou o trabalho está parado em revisão e não passou pela Definition of Done. Verifique o sistema de acompanhamento primeiro antes de presumir que a equipe parou de trabalhar.

O que é a linha ideal do Burndown?

A linha ideal é uma diagonal reta que vai do comprometimento total do Sprint no Dia 0 até zero no último dia. Ela representa progresso diário perfeitamente uniforme. Nenhum Sprint real se parece com isso, e tudo bem. Ela existe como ponto de referência para que a equipe possa ver o quanto o progresso real desvia de uma linha de base teórica.

Qual é a diferença entre Burndown e Velocity?

Um Burndown chart mostra o trabalho restante dentro de um único Sprint. A Velocity mede quantos Story Points uma equipe concluiu em múltiplos Sprints, geralmente com média dos últimos três a cinco. O Burndown é um sinal dentro do Sprint. A Velocity é uma tendência entre Sprints. Ambos importam para o planejamento do Sprint: a Velocity diz quanto comprometer, o Burndown diz se você está entregando conforme o comprometimento.

Devo usar Story Points ou horas?

Qualquer um funciona. Story Points são mais comuns em equipes de engenharia de produto porque abstraem diferenças individuais de habilidade e focam na complexidade relativa. Horas funcionam bem para equipes com tipos de tarefa altamente previsíveis, como suporte ou design. A regra mais importante é a consistência: escolha uma unidade para sua equipe e não mude no meio do projeto, ou seus gráficos tornam-se impossíveis de comparar ao longo do tempo.

Com que frequência devo atualizar um Burndown chart?

Diariamente é o padrão. Atualizar no standup diário ou ao final do dia mantém o gráfico preciso o suficiente para identificar problemas cedo. Atualizações semanais deixam uma semana inteira de risco invisível. Algumas equipes atualizam duas vezes ao dia durante Sprints de alta importância, embora diariamente seja suficiente para a maioria das situações.

---

Os Burndown charts funcionam porque revelam a realidade rapidamente. Uma equipe que observa seu Burndown toda manhã não consegue se esconder de um Sprint ruim por muito tempo, e essa visibilidade é exatamente o que o torna útil. Seja usando Scrum, experimentando com Kanban ou gerenciando um projeto de método misto pelo método do caminho crítico, o Burndown chart oferece uma visão limpa e honesta do progresso. Comece a acompanhar hoje e você descobrirá que ele se torna uma das primeiras coisas que a equipe verifica a cada manhã.