A maioria dos squads só percebe que um sprint está fora do trilho quando já é tarde demais para corrigir o rumo. Um burndown chart torna esse risco visível em tempo real, mostrando exatamente quanto trabalho resta em relação ao tempo disponível. É um gráfico de linha que plota o trabalho restante ao longo do tempo em um sprint ou projeto, com uma linha de progresso ideal como referência. Esta página cobre a definição, como medir e ler um burndown chart, benchmarks, erros comuns e como o DevStats mostra dados de progresso de sprint para líderes de engenharia.
Key takeaways
- Um burndown chart é uma ferramenta visual usada por times ágeis e Scrum para acompanhar quanto trabalho resta em um sprint ou release em relação a um ritmo ideal projetado. Ele dá aos líderes de engenharia um sinal de alerta antecipado quando a entrega está em risco, antes que o sprint termine e os stakeholders comecem a fazer perguntas.
- O gráfico plota story points ou tarefas restantes no eixo Y e dias corridos no eixo X. A linha ideal do burndown vai do escopo total no primeiro dia até zero no último dia. Não existe um benchmark de mercado publicado para o formato do burndown, já que ele varia por tamanho do time, duração do sprint e forma de estimativa. Um padrão recorrente de terminar acima de zero, porém, é um sinal que vale investigar.
- O erro mais comum dos squads é tratar o burndown chart como um artefato de reporte em vez de uma ferramenta ativa de gestão. Eles revisam no sprint retrospective depois que o estrago já foi feito, em vez de checar no meio do sprint para identificar bloqueios, scope creep ou gaps de estimativa enquanto ainda dá tempo de agir.
- O DevStats se conecta ao seu issue tracker e ao seu provedor Git para mostrar dados de progresso de sprint automaticamente, com contexto de precisão de planejamento e benchmarks de throughput de mais de 1.000 times de engenharia. Comece um trial gratuito e veja a saúde do sprint do seu squad em menos de dois minutos.
Definição de burndown chart
Um burndown chart é um gráfico que mostra quanto trabalho resta em um sprint ou projeto ao longo do tempo. Ele plota o trabalho restante (medido em story points, quantidade de tarefas ou horas) no eixo Y e o tempo no eixo X, com uma linha "ideal" reta que mostra o ritmo necessário para terminar no prazo.
O gráfico é lido comparando a linha real do burndown com a linha ideal. Se a linha real está acima da ideal, o squad está abaixo do ritmo esperado. Se está abaixo, está adiantado. O gráfico não calcula um número único. É um diagnóstico visual. Quando um squad termina sprints com trabalho restante de forma consistente, esse padrão aponta para problemas de estimativa, scope creep ou atrito no processo. Entrega confiável de sprint conecta diretamente à confiança dos stakeholders e à previsibilidade do produto. Por isso esse gráfico aparece em quase toda conversa de planejamento ágil. O recurso de precisão de planejamento do DevStats dá aos líderes de engenharia uma visão quantitativa de quão bem os compromissos do sprint batem com os resultados ao longo do tempo.
Por que burndown charts importam para times de engenharia
Sem um burndown chart (ou uma visão equivalente do progresso do sprint), líderes de engenharia ficam no escuro até o último dia do sprint. Scope creep, trabalho não planejado e gaps de estimativa ficam invisíveis até virarem compromissos perdidos. Nesse ponto, o squad já absorveu o custo e os stakeholders já estão desapontados.
Para um VP de Engenharia, o burndown chart é um indicador antecedente que conecta diretamente à entrega no prazo e à previsibilidade do time. Padrões persistentes de burndown acima do ideal costumam sinalizar que o sprint planning está quebrado, que players estão bloqueados por dependências ou que trabalho está sendo adicionado no meio do sprint sem remover outra coisa. São problemas de processo, não de pessoas. O gráfico dá ao líder de engenharia os dados para nomear o padrão antes que ele vire um modo de falha recorrente. Você pode ver como os dados de nível de sprint se encaixam em uma visão mais ampla de entrega pelo recurso de sprints do DevStats, que rastreia taxas de conclusão de sprint e mudanças de escopo em todos os seus squads.
O SPACE framework trata previsibilidade e eficiência como dimensões centrais da saúde de engenharia. Um burndown chart é uma das formas mais diretas de medir as duas no nível do sprint. A medição revela o padrão. O líder de engenharia decide o que fazer com ele.
Como medir um burndown chart
Para construir um burndown chart, você precisa de três insumos: total de trabalho comprometido no início do sprint (em story points ou quantidade de tarefas), trabalho restante em cada ponto no tempo e a data de término do sprint. A linha ideal é calculada dividindo o escopo total pelo número de dias úteis do sprint e plotando uma linha reta do escopo total no primeiro dia até zero no último dia. A linha real atualiza diariamente conforme o trabalho é concluído e marcado como feito no seu issue tracker.
A fonte de dados principal é o seu issue tracker (Jira, Linear, GitHub Issues ou similar). O trabalho é contado como "restante" até atingir o estado fechado ou concluído. Mudanças de escopo no meio do sprint, como tickets adicionados ou removidos, devem ser refletidas no gráfico para dar uma visão precisa. Alguns times também rastreiam uma linha separada para mudanças de escopo, para distinguir "terminamos mais rápido" de "removemos trabalho".
Nenhum benchmark publicado define como um burndown chart deve parecer, já que o formato varia por tamanho do time, duração do sprint, abordagem de estimativa e tipo de trabalho. A tabela abaixo descreve o que diferentes padrões sinalizam na prática. Você pode comparar os padrões do seu squad com times pares usando os benchmarks do DevStats.
| Nível de desempenho | Padrão do burndown chart | O que sinaliza |
|---|---|---|
| Elite | Linha real acompanha de perto a ideal durante todo o sprint e termina em zero ou próximo de zero | Precisão de estimativa consistente, baixa interrupção no meio do sprint, entrega previsível |
| Alto | Linha real fica acima da ideal no início, mas se recupera e termina próxima de zero | Algum atrito inicial ou começos lentos, mas o squad se autocorrige dentro do sprint |
| Médio | Linha real fica acima da ideal na maior parte do sprint e termina com algum trabalho restante | Gaps de estimativa ou bloqueios no meio do sprint não resolvidos. Padrão recorrente merece investigação |
| Baixo | Linha real está plana ou sobe no meio do sprint. Trabalho significativo resta no final do sprint | Scope creep, trabalho bloqueado ou processo de planejamento quebrado. Compromissos de entrega são pouco confiáveis |
Nota: esses padrões são descritores qualitativos, não limites padronizados pelo mercado. Benchmarks variam por tamanho do time, maturidade do codebase e modelo de release.
Burndown chart na prática: um exemplo real
Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que seus squads terminavam sprints consistentemente com 15 a 20% do trabalho comprometido incompleto. Os burndown charts mostravam uma linha plana nos primeiros três dias de cada sprint de duas semanas, seguida de uma queda acentuada nos dois últimos dias. Esse formato indicou que o problema não era capacidade. Os players estavam concluindo o trabalho, mas começando tarde. Ao revisar os dados, ela identificou que as sessões de sprint planning terminavam sem breakdowns claros de tarefas, deixando os players para descobrir o escopo por conta própria no início de cada sprint. Ela reestruturou o planejamento para exigir breakdowns em nível de subtarefa antes do sprint começar.
Nos dois sprints seguintes, as linhas do burndown começaram a cair desde o primeiro dia. As taxas de conclusão melhoraram e a correria do final do sprint desapareceu. Ela acompanhou a mudança usando dados de precisão de planejamento junto com a visão do burndown para confirmar que o padrão estava se mantendo, não era só uma anomalia de um sprint. Os dados deram o sinal. A intervenção foi dela para desenhar e executar.
Como melhorar a saúde do seu burndown chart
- Quebre as stories em tarefas antes do sprint começar. Stories vagas ficam intocadas na primeira metade do sprint porque os players ainda estão descobrindo o que "pronto" significa. Exigir breakdowns em nível de subtarefa durante o sprint planning força clareza antecipada e coloca o trabalho em movimento desde o primeiro dia. Fique de olho em stories sem subtarefas como indicador antecedente de começos lentos.
- Estabeleça um congelamento de escopo após o primeiro dia. Adições no meio do sprint são uma das causas mais comuns de uma linha de burndown subindo. Crie uma regra de que trabalho novo adicionado após o primeiro dia do sprint ou substitui trabalho comprometido existente ou vai para o backlog do próximo sprint. Isso protege a capacidade do squad de entregar o que comprometeu.
- Revise o burndown chart na standup do meio do sprint, não só na retrospective. Um check-in no meio do sprint (dia cinco de um sprint de dez dias) dá tempo para agir. Se a linha real está significativamente acima da ideal na metade do caminho, você pode remover escopo, tratar bloqueios ou ajustar expectativas antes do sprint terminar. Esperar até a retrospective transforma uma ferramenta de diagnóstico em um post-mortem.
- Use o cycle time de issues como métrica complementar. Um burndown chart diz quanto trabalho resta. O cycle time de issues diz quanto tempo tickets individuais levam para ir de em andamento para concluído. Se o cycle time está alto, o trabalho está travando em algum ponto do processo, e esse atrito vai aparecer como uma linha de burndown plana.
- Audite a precisão de estimativa sprint a sprint. Se seu burndown termina consistentemente acima de zero, o processo de estimativa é o primeiro lugar para olhar. Os dados de precisão de planejamento do DevStats podem mostrar quais tipos de trabalho são consistentemente subestimados, para você ajustar suas convenções de pontuação em vez de só torcer para o próximo sprint ir melhor.
Burndown chart vs. burnup chart
Um burndown chart e um burnup chart medem o progresso do sprint de formas diferentes, e os times frequentemente os confundem porque parecem similares à primeira vista. Um burndown chart mostra o trabalho restante diminuindo em direção a zero. Um burnup chart mostra o trabalho concluído aumentando em direção à linha de escopo total, com mudanças de escopo visíveis como uma linha separada em movimento no topo.
| Burndown chart | Burnup chart | |
|---|---|---|
| Mede | Trabalho restante | Trabalho concluído |
| Começa quando | Sprint inicia com o escopo total | Sprint inicia em zero concluído |
| Termina quando | Linha chega a zero se todo o trabalho for feito | Linha de concluído encontra a linha de escopo se todo o trabalho for feito |
| Melhor para | Acompanhar o ritmo em direção à conclusão e identificar desacelerações | Mostrar mudanças de escopo explicitamente e comunicar progresso aos stakeholders |
Use um burndown chart quando quiser uma visão rápida de se o squad está no ritmo. Use um burnup chart quando o escopo muda com frequência e você precisa que os stakeholders vejam tanto o progresso quanto o movimento de escopo em uma única visão. Os dados de throughput do DevStats complementam os dois mostrando quantos itens de trabalho são concluídos por período.