Sprint burndown

A maioria dos squads termina um sprint e só então descobre que estava fora do ritmo desde o dia três. O gráfico de sprint burndown é o sinal que te avisa antes, mostrando quanto trabalho resta em relação ao tempo disponível no sprint. Quando a linha de progresso real do seu squad sobe acima da linha ideal, você tem um problema de planejamento ou execução que vale investigar. Esta página cobre a definição, como medir, o que é um bom resultado e como agir com base nos dados.

Principais conclusões

• O sprint burndown mostra quanto trabalho resta no sprint em qualquer momento, comparado ao progresso linear ideal em direção a zero. Ele importa porque dá aos líderes de engenharia um sinal dentro do sprint, não apenas na retrospectiva, para identificar riscos de entrega antes que virem um compromisso perdido.
• Para plotar um sprint burndown, divida o total de story points (ou horas de tarefa) comprometidos no início do sprint pelo número de dias do sprint para obter a taxa de burn diária ideal. Depois, acompanhe o trabalho restante real a cada dia. Não existe um benchmark universal publicado, mas um squad que termina consistentemente dentro de 10% do escopo comprometido é um sinal saudável.
• O erro mais comum dos times é tratar o burndown como um artefato de reporte em vez de uma ferramenta de diagnóstico. Squads que só revisam o burndown nas reuniões de retrospectiva perdem a oportunidade, dentro do próprio sprint, de replanejar, reduzir escopo ou identificar bloqueios antes que o sprint termine.
• O DevStats exibe dados de saúde do sprint automaticamente ao se conectar ao seu issue tracker, com visibilidade sobre tendências de precisão de planejamento entre sprints e benchmarks em relação a times semelhantes. Inicie um teste gratuito em app.devstats.com/register e veja os números do seu squad em menos de dois minutos.

Definição de sprint burndown

O sprint burndown é um gráfico que acompanha a quantidade de trabalho restante em um sprint ao longo do tempo, plotada contra um caminho de linha reta ideal que vai do total de trabalho comprometido até zero no último dia do sprint. Ele dá aos times de engenharia um sinal visual diário sobre se estão no ritmo para concluir tudo que comprometeram.

Tecnicamente, o gráfico plota duas linhas: o burndown ideal (total de story points dividido igualmente pelos dias do sprint) e o burndown real (pontos restantes atualizados a cada dia conforme o trabalho é concluído). Quando a linha real sobe acima da ideal, escopo foi adicionado ou o trabalho está parado. Quando cai abaixo, o squad está adiantado ou o escopo foi reduzido. Um burndown saudável se conecta diretamente à confiança dos stakeholders: entregas previsíveis constroem confiança nos compromissos de engenharia. Você pode ver como o DevStats exibe isso pelo recurso Sprints, que rastreia dados de conclusão no nível do sprint em todos os seus squads.

Por que o sprint burndown importa para times de engenharia

Squads que pulam as revisões diárias do burndown frequentemente chegam ao oitavo dia de dez antes que alguém reconheça que não vão terminar. A essa altura, as únicas opções são esforço heroico ou um compromisso perdido. Nenhuma das duas é boa para o time ou para os stakeholders. O sprint burndown é o sinal de processo mais antecipado de que algo precisa mudar no meio do sprint, seja reduzir escopo, remover um bloqueio ou redistribuir trabalho entre os players.

Para líderes de engenharia, as tendências de burndown em múltiplos sprints se conectam diretamente às taxas de entrega no prazo e à precisão de planejamento. Um squad que consistentemente tem um burn plano na primeira metade do sprint e então corre no final tem um problema diferente de um que queima de forma suave, mas sempre carrega um ou dois itens para o próximo sprint. Os dois padrões são visíveis nos dados e os dois exigem intervenções diferentes do engineering manager. Times que fazem benchmark da performance do sprint em relação a peers conseguem distinguir entre um problema de processo e um problema de capacidade mais rapidamente.

Dentro do SPACE framework, o sprint burndown se mapeia mais diretamente às dimensões de Atividade e Eficiência: ele reflete se o trabalho está fluindo pelo sistema conforme planejado. Medir de forma consistente é o primeiro passo. O que você faz com o padrão é o trabalho do líder de engenharia.

Como medir o sprint burndown

Comece com o total de story points ou horas de tarefa comprometidos no planejamento do sprint. Divida esse total pelo número de dias úteis no sprint para obter sua taxa de burn diária ideal. A cada dia, subtraia o trabalho concluído do total restante e plote o resultado. Seu issue tracker (Jira, Linear, GitHub Issues) é a fonte de dados principal. Dados do Git não são necessários para um burndown básico, mas conectar a atividade do Git à conclusão de issues ajuda a validar se "pronto" significa merged e em deploy, e não apenas movido para uma coluna de concluído.

Não existe um benchmark publicado universalmente para sprint burndown da mesma forma que existem DORA benchmarks para frequência de deployment ou taxa de falha de mudanças. O que é "bom" varia pelo tamanho do time, duração do sprint e natureza do trabalho. A tabela abaixo descreve níveis qualitativos de performance com base em padrões comuns entre times de engenharia. O recurso de benchmarks do DevStats oferece comparações com peers que adicionam contexto que seus próprios dados históricos não conseguem.

Os benchmarks variam pelo tamanho do time, duração do sprint e maturidade do codebase. Use esses valores como sinais direcionais, não como limites rígidos.

Sprint burndown na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que seus squads estavam atingindo consistentemente 85% de conclusão do sprint em três sprints consecutivos. Os gráficos de burndown mostravam todos o mesmo padrão: plano nos primeiros quatro dias, depois uma queda acentuada nos dois últimos. Ela puxou os dados e descobriu que a maioria dos itens estava sendo movida para "em revisão" no dia seis, o que significava que o code review era o gargalo, não o desenvolvimento. O trabalho estava sendo feito, mas não passava pela revisão rápido o suficiente para contar como concluído antes do fim do sprint.

Ela fez uma mudança: definiu uma norma no squad de que qualquer PR aberto por mais de 24 horas teria uma solicitação de revisão escalada no standup. Ela acompanhou o tempo de retorno do code review junto com o burndown no sprint seguinte. A conclusão do sprint melhorou para 94% e a correria no final do sprint desapareceu. Os dados do burndown mostraram onde olhar. Ela decidiu o que fazer com isso.

Como melhorar o sprint burndown

1. Limite o tamanho das stories a meio dia de sprint. Stories grandes são a causa mais comum de burndowns planos na primeira metade do sprint. Se uma story não pode ser concluída e revisada em menos de quatro horas, quebre-a antes do planejamento do sprint. Fique atento a stories que ficam "em andamento" por mais de dois dias sem nenhum movimento.
2. Revise o burndown no standup diário, não só na retrospectiva. Deixe o gráfico visível todos os dias. Quando a linha real sobe acima da ideal no dia três, esse é o momento de perguntar o que está bloqueado, não no dia nove. O trabalho do engineering manager é abrir o caminho, e você não consegue fazer isso se só olha para os dados uma vez por semana.
3. Registre mudanças de escopo explicitamente. Toda adição no meio do sprint deve ser registrada e compensada por uma remoção. Squads que adicionam escopo sem remover nada sempre terão um burndown que parece estar falhando, mesmo quando o time está performando bem. Mudanças de escopo visíveis tornam o gráfico honesto.
4. Monitore o cycle time de issues como indicador antecipado. Se o cycle time médio por issue está aumentando entre sprints, seu burndown vai começar a derivar antes de você perceber nas taxas de conclusão do sprint. O cycle time te dá o sinal mais cedo. O DevStats exibe as duas métricas na mesma visualização, então você vê a relação diretamente.
5. Verifique os padrões de alocação quando o burndown está consistentemente plano. Às vezes, burns lentos não são problemas de estimativa. São problemas de capacidade: players divididos entre squads demais ou trabalho não planejado demais tirando-os dos compromissos do sprint. Os dados de alocação mostram se o problema é de planejamento ou de banda.

Sprint burndown vs. sprint velocity

Sprint burndown e sprint velocity são relacionados, mas medem coisas diferentes: o burndown mostra se o seu squad está no ritmo dentro de um sprint, enquanto a velocity mede quanto trabalho um squad conclui entre sprints ao longo do tempo.

Use o burndown para gerenciar o sprint atual e a velocity para planejar o próximo. Os dados de throughput no DevStats complementam os dois ao mostrar com que consistência os itens de trabalho estão sendo concluídos ao longo do tempo.