Gráfico burndown: como ler e agir a tempo na sprint

O que é o gráfico burndown

O gráfico burndown (ou burndown chart) é a forma mais simples de enxergar, num relance, se a sprint vai fechar dentro do combinado. Ele mostra quanto trabalho ainda falta, dia após dia: o eixo vertical traz os pontos restantes (ou a quantidade de itens, se o time não estima em pontos) e o eixo horizontal traz os dias da sprint. No primeiro dia, a linha começa no total planejado; a cada item concluído, ela desce. Se tudo correr bem, chega a zero no último dia.

O que dá poder ao burndown é a linha ideal: uma reta que desce em ritmo constante, do total de pontos no dia 1 até zero no último dia. Ela representa o ritmo teórico "perfeito" — e serve de régua. Comparando a linha real (o que de fato aconteceu) com a ideal (o que precisaria acontecer), qualquer pessoa do time percebe em segundos se a entrega está adiantada, atrasada ou no rumo — sem planilha, sem reunião de status, sem depender de alguém "sentir" que a sprint vai mal.

Um detalhe que muda tudo: o burndown mede trabalho restante, não trabalho feito. Essa escolha é proposital. "Quanto já fizemos" alimenta o ego; "quanto ainda falta e quantos dias restam" alimenta decisões. É por isso que o gráfico se tornou o painel padrão de qualquer time que trabalha em sprints — de engenharia a marketing, de RH a eventos.

Como o gráfico é construído na prática

Para desenhar um burndown você precisa de três ingredientes que qualquer time que fez uma boa montagem de sprint já tem:

1. O total planejado. A soma dos pontos (ou dos itens) que o time se comprometeu a entregar na sprint. Se o time estima com story points, é a soma dos pontos das User Stories; se não estima, contar itens já funciona.
2. A duração da sprint. Uma sprint de duas semanas com dias úteis vira um eixo de 10 dias.
3. A atualização diária. Ao fim de cada dia (ou na daily do dia seguinte), registra-se quantos pontos ainda restam. Item concluído sai da conta; item pela metade continua contando inteiro — no burndown clássico, só o "pronto de verdade" faz a linha descer.

Um exemplo fora da TI para fixar: o time de marketing da Renata planejou uma sprint de 10 dias com 40 pontos — landing page da campanha (8), sequência de e-mails (5), três peças para redes sociais (3 cada), briefing e gravação de dois vídeos (8 e 5), e ajustes no site (5 no total). A linha ideal desce 4 pontos por dia. No dia 3, se o time concluiu a sequência de e-mails e uma peça de rede social, restam 32 pontos — a linha real está em 32 contra 28 da ideal. Nada dramático ainda, mas já é informação: o time está um dia atrás do ritmo.

Se o board da sprint estiver sempre atualizado, o gráfico se desenha sozinho. No TeamBOX, por exemplo, o burndown é automático: cada User Story que chega à coluna final do board faz a linha descer na hora, e o termômetro da sprint compara pontos, tempo e entrega para avisar o gestor quando o ritmo desanda — ninguém precisa montar planilha na sexta-feira.

A regra de ouro: leia a tendência, não o dia

Antes dos padrões, uma calibragem importante: nenhum dia isolado do burndown significa nada. Trabalho de verdade não conclui em parcelas idênticas — um item de 8 pontos leva três dias sem mover a linha e, quando termina, ela despenca de uma vez. Por isso a linha real saudável parece uma escada torta, não uma rampa lisa.

O que interessa é a tendência ao longo de vários dias: a linha real está consistentemente colada na ideal, consistentemente acima, ou consistentemente abaixo? É essa leitura acumulada que separa ruído de sinal. Times imaturos entram em pânico no primeiro dia em que a linha "não desceu"; times experientes olham o desenho da semana.

Com essa lente, os quatro padrões clássicos ficam fáceis de reconhecer.

Os 4 padrões clássicos do burndown

1. Saudável: escada torta colada na linha ideal

A linha real desce em degraus irregulares, ora um pouco acima, ora um pouco abaixo da ideal, e chega perto de zero no último dia. É o padrão de um time que fatiou bem o trabalho: itens pequenos o bastante para concluir a cada 1–3 dias, o que gera degraus frequentes.

O que fazer: quase nada — e isso é uma virtude. Vale registrar na retrospectiva o que tornou a sprint previsível (tamanho dos itens? menos interrupções? critérios de aceite claros?) para repetir de propósito, e não por sorte.

2. Platô que despenca no fim: a "barriga" perigosa

A linha fica praticamente reta durante dias — às vezes a sprint inteira — e despenca de uma vez nos últimos dois dias. Visto de longe, a sprint "fechou". Visto de perto, o time passou 80% do tempo sem nenhuma confirmação de que fecharia.

As causas mais comuns são duas, e é importante distinguir:

• Itens grandes demais. Se cada item leva sete dias para concluir, a linha só pode descer no fim. O problema não é o time; é a fatia. Exemplo: o time de RH do Teodoro colocou "reformular o processo de onboarding" como um item único de 13 pontos. Nada "termina" até a véspera da review. Quebrado em fatias — mapear o processo atual, redesenhar a trilha da primeira semana, escrever o guia do gestor, testar com dois contratados — a linha desceria quatro vezes ao longo da sprint.
• Board desatualizado. O trabalho até concluiu ao longo dos dias, mas ninguém moveu os cards; na véspera da review alguém "arruma o board" e a linha despenca. Aqui o burndown não está medindo a entrega — está medindo a disciplina de atualização.

O que fazer ainda na sprint: na próxima daily, pergunte item por item: "o que falta para este concluir?". Se a resposta for vaga, quebre o item ali mesmo em sub-tarefas com dono e dia. E combine o básico: card se move quando o trabalho muda de estado, não quando alguém lembra.

3. Sempre acima da linha ideal: sprint gorda

A linha real corre paralela à ideal, mas persistentemente acima — dia após dia falta mais trabalho do que deveria faltar. Tradução direta: entrou mais trabalho na sprint do que o time consegue entregar. Ou o planejamento foi otimista demais, ou trabalho novo entrou pela lateral depois do compromisso (o famoso "só mais essa coisinha").

Exemplo: o time de produto da Camila planejou 45 pontos numa sprint em que historicamente entrega 34. No dia 4, a linha real está em 36 contra 27 da ideal — e a distância só cresce. Matematicamente, essa sprint não fecha. A pergunta não é mais "se" algo vai ficar de fora; é "o quê".

O que fazer ainda na sprint — e cedo:

• Reconheça a matemática em voz alta. Dividir os pontos restantes pelos dias restantes e comparar com o ritmo real do time tira a conversa do campo da esperança.
• Repriorize com o dono do backlog. Decidam juntos o que sai, começando pelo que tem menor valor — e devolvam esses itens ao backlog, sem culpa. Escopo negociado no dia 4 é gestão; escopo estourado descoberto no dia 10 é incêndio.
• Avise quem depende da entrega. Um "não vai dar tempo de tudo; priorizamos X e Y, Z fica para a próxima" no meio da sprint preserva confiança. Silêncio até a review a destrói.
• Feche a porta lateral. Se a gordura veio de trabalho não planejado, todo pedido novo passa a entrar só com troca explícita: entra um, sai outro do mesmo tamanho.

4. Queda cedo demais: sprint magra

A linha real despenca bem abaixo da ideal já nos primeiros dias e o time "termina" a sprint com dias de sobra. Parece ótimo — e às vezes é só um time que evoluiu. Mas o padrão recorrente costuma esconder outra coisa: estimativas infladas ou planejamento tímido demais. O time se compromete com menos do que consegue, garante o "sucesso" no gráfico e deixa capacidade na mesa.

Há uma causa mais sutil e mais séria: se o burndown virou instrumento de cobrança, inflar estimativas é a defesa racional do time. Sprint magra crônica é, muitas vezes, sintoma de medo — e o remédio não é técnico.

O que fazer ainda na sprint: puxe os próximos itens do topo do backlog e siga entregando — sprint com folga não é férias, é oportunidade. E marque a conversa para a retrospectiva: as estimativas estão calibradas? O compromisso foi tímido? Há medo de errar o gráfico? Times que jogam Planning Poker com discussão honesta das divergências tendem a recalibrar rápido.

Agir durante a sprint, não depois dela

Repare no fio comum dos quatro padrões: todas as correções acontecem com a sprint em andamento. Essa é a única razão de existir do burndown. Um gráfico que só é olhado na retrospectiva é um atestado de óbito — bem desenhado, mas inútil para o paciente.

O ritual que funciona é simples: o burndown aberto na daily, 30 segundos, uma pergunta — "esse desenho conta a história certa sobre a nossa sprint?". Se sim, sigam. Se não, a daily é exatamente o fórum para decidir a correção do dia: quebrar um item, pedir ajuda em um bloqueio, renegociar escopo, avisar um interessado. Quem quiser ir além do trabalho restante pode compor a leitura com outras métricas de sprint, mas para a decisão do dia a dia o burndown sozinho já carrega o essencial.

Vale para qualquer área. O time de eventos do Igor, organizando uma convenção de vendas em sprints semanais, viu no dia 3 a linha empacada por causa de um item só: "fechar contrato com o buffet", travado no jurídico. O burndown não resolveu o contrato — mas fez o bloqueio ficar visível a tempo de o gestor escalar o assunto naquele dia, e não na semana seguinte.

Burndown não é chicote

Uma advertência que precisa de seção própria: o burndown mede o trabalho restante do time, e nada mais. Ele não mede esforço, não mede dedicação e não mede pessoas.

Quando um gestor usa o gráfico para cobrar indivíduos — "a linha não desceu ontem, o que você estava fazendo?" —, o time aprende em uma sprint a se defender: estimativas incham, itens são dados como "prontos" antes da hora, o board vira teatro. O gráfico continua bonito e para de dizer a verdade. Você troca um instrumento de navegação por um enfeite — e perde justamente o alerta antecipado que o justificava.

O uso maduro é o oposto: o burndown pertence ao time, é lido em conjunto e toda anomalia gera uma pergunta curiosa antes de qualquer julgamento. "A linha empacou — o que está nos travando e como eu ajudo?" produz informação; "por que vocês estão atrasados?" produz maquiagem. Um dia isolado ruim não significa nada; uma tendência de três ou quatro dias significa conversa — com o time, não contra ele.

Erros comuns ao ler o burndown (checklist rápido)

Antes de tirar conclusões do gráfico, passe por esta lista:

• Julgar um dia isolado. A linha real saudável é uma escada torta. Leia tendências de 3+ dias, nunca o degrau de ontem.
• Exigir a linha colada na ideal. A ideal é régua, não meta. Um time real oscila em torno dela — desvio persistente é sinal; oscilação é vida.
• Contar item pela metade como progresso. No burndown clássico, só o concluído desce a linha. "90% pronto" que fica 90% pronto por quatro dias é exatamente o que o platô denuncia.
• Deixar o escopo crescer sem registrar. Se entra trabalho novo, o total deve subir no gráfico (a linha real "sobe" naquele dia). Esconder a adição transforma o burndown em ficção.
• Montar o gráfico à mão na sexta-feira. Burndown atualizado em lote perde a única vantagem que tem: o alerta diário. Automatize — se o board é a fonte da verdade, o gráfico deve nascer dele sozinho, como no burndown automático do TeamBOX.
• Usar o gráfico em conversa de desempenho individual. Para avaliar pessoas existem instrumentos melhores e mais justos; o burndown avalia o plano da sprint, não quem a executa.
• Olhar só na retrospectiva. Aí já virou autópsia. O valor do burndown está em agir no dia 4, quando ainda dá tempo de mudar o final da história.