Burndown e velocidade do time: como ler e usar na sprint
O gráfico burndown é a imagem mais conhecida do Scrum e também uma das mais mal usadas. Em muitos times, ele vira um termômetro de cobrança: a linha real ficou acima da ideal, o gestor pergunta o que deu errado, e na Sprint seguinte o time passa a quebrar tarefas de um jeito que faz a linha descer bonita, sem que o produto avance mais rápido por isso.
Bem usado, o burndown responde a uma pergunta simples: no ritmo atual, vamos chegar ao fim da Sprint (ou da entrega) com o que planejamos? A velocidade do time responde a outra: quanto trabalho esse time costuma concluir por Sprint? Juntas, as duas informações ajudam o Product Owner a prever entregas e ajudam o time a perceber cedo que o plano precisa mudar.
Abaixo estão os formatos de leitura mais comuns, a relação entre burndown, burnup e velocidade e os cuidados para que a métrica sirva ao time, e não o contrário.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é o gráfico burndown
O burndown é um gráfico de trabalho restante ao longo do tempo. No eixo horizontal ficam os dias da Sprint; no vertical, o trabalho que ainda falta. A unidade pode ser story points, número de itens do backlog ou horas estimadas das tarefas. Uma linha reta, do total planejado no primeiro dia até zero no último, serve de referência. A linha real é atualizada todo dia.
Existem dois usos principais:
- Burndown da Sprint: acompanha o Sprint Backlog dia a dia. Ajuda os Developers a perceber se o plano para alcançar a Meta da Sprint ainda é viável.
- Burndown da entrega (release): acompanha o backlog de uma entrega maior Sprint a Sprint. Ajuda o Product Owner a conversar com as partes interessadas sobre datas e escopo.
O Guia do Scrum 2020 menciona burn-downs, burn-ups e fluxo cumulativo como práticas que existem para prever o progresso, e completa que, embora úteis, elas não substituem a importância do empirismo. Ou seja: o gráfico é opcional e é uma previsão, não um compromisso. Quem garante a transparência do trabalho é o Sprint Backlog, que o guia descreve como uma imagem altamente visível e em tempo real do que os Developers planejam fazer.
Como montar o burndown da Sprint
- Escolha a unidade. Para o burndown da Sprint, contar itens ou pontos dos itens concluídos funciona melhor do que horas de tarefas, porque mede entrega, não esforço. Horas restantes só fazem sentido se o time já trabalha com tarefas pequenas e reestima todo dia.
- Defina o que conta como queimado. Um item só desce do gráfico quando atende à Definição de Pronto. Item "quase pronto" não queima.
- Registre o total no fim da Sprint Planning. É o ponto de partida da linha.
- Atualize no mesmo horário todo dia. O melhor momento é logo antes da Daily Scrum, para o time olhar o gráfico junto.
- Mostre as mudanças de escopo. Se um item entrou ou saiu no meio da Sprint, anote no gráfico. Sem essa anotação, um degrau para cima parece atraso.
Ferramentas como Jira geram o gráfico automaticamente a partir dos status do quadro. Uma planilha também resolve: uma coluna de dias, uma de trabalho restante e uma de linha ideal.
Como ler um burndown: os padrões mais comuns
A leitura vale mais do que o desenho. Os padrões abaixo aparecem em quase todo time e cada um pede uma conversa diferente.
| Padrão | O que costuma indicar | Pergunta para a Daily ou para a Retrospectiva |
|---|---|---|
| Linha real acompanha a ideal | Itens pequenos, fluxo contínuo | O que estamos fazendo certo e não podemos perder? |
| Linha plana nos primeiros dias, queda brusca no fim | Itens grandes ou teste concentrado no fim | Como fatiar os itens para concluir algo nos primeiros dias? |
| Linha sobe no meio da Sprint | Escopo adicionado ou item reestimado | Quem pediu, por quê e o que saiu para compensar? |
| Linha nunca chega a zero, Sprint após Sprint | Planejamento acima da capacidade | A previsão está usando a velocidade real ou a desejada? |
| Linha chega a zero no meio da Sprint | Planejamento abaixo da capacidade ou itens subestimados | O time puxou mais trabalho do backlog ou ficou ocioso? |
| Degraus grandes e irregulares | Itens desiguais, alguns enormes | Os itens estão prontos para entrar na Sprint? |
O padrão "plano e depois cai de uma vez" é o mais comum em times que começam com Scrum. Ele mostra que o trabalho só fica pronto quando tudo fica pronto, o que esconde risco até o último dia. A correção não está no gráfico, está no refinamento: itens menores, com critério de aceite claro, que possam ser concluídos e testados em um ou dois dias.
Velocidade do time: o que mede e o que não mede
Velocidade (velocity) é a quantidade de trabalho que o time concluiu numa Sprint, somando os pontos dos itens que atenderam à Definição de Pronto. A palavra não aparece no Guia do Scrum; é uma prática complementar, popular em times que estimam com planning poker e story points.
A velocidade só é útil como média de várias Sprints. Uma Sprint isolada sofre com férias, feriados, incidentes em produção e itens que mudaram no caminho. Uma regra prática é usar a média das últimas três a cinco Sprints e observar a faixa entre a menor e a maior, em vez de um número único.
O que a velocidade não mede:
- Produtividade individual. Os pontos são do time, não das pessoas.
- Valor entregue. Um time pode concluir muitos pontos de itens que ninguém usa.
- Comparação entre times. Cada time calibra a escala do seu jeito. Comparar 30 pontos de um com 50 de outro não diz nada.
Quando a velocidade vira meta ("precisamos chegar a 60 pontos"), o time passa a inflar estimativas, e o número sobe sem que nada mude. É o mesmo efeito que o gráfico burndown sofre quando vira instrumento de cobrança.
Burndown, burnup e velocidade: quando usar cada um
O burnup mostra duas linhas: o trabalho concluído, que sobe, e o escopo total, que pode subir ou descer. A diferença entre as duas é o que falta. Ele resolve a principal fraqueza do burndown, que mistura progresso e mudança de escopo numa linha só.
| Situação | Melhor visualização |
|---|---|
| Acompanhar a Sprint no dia a dia | Burndown da Sprint |
| Escopo da entrega estável | Burndown da entrega |
| Escopo da entrega muda com frequência | Burnup da entrega |
| Prever quantas Sprints faltam | Burnup com faixa de velocidade (otimista e pessimista) |
| Time que trabalha em fluxo contínuo, sem Sprints | Diagrama de fluxo cumulativo e tempo de ciclo |
Para times que usam Kanban, métricas de fluxo como lead time, tempo de ciclo e throughput costumam dizer mais do que pontos. O artigo sobre métricas do Kanban explica como montar e ler cada uma.
Como prever uma entrega com velocidade: exemplo ilustrativo
Imagine um time que desenvolve um portal de serviços para uma prefeitura. O backlog da primeira entrega soma 180 pontos. Nas últimas cinco Sprints, de duas semanas, o time concluiu 28, 34, 31, 25 e 32 pontos.
- Calcule a faixa. Média de 30 pontos; o pior caso recente foi 25 e o melhor, 34.
- Projete os cenários. 180 pontos divididos por 34 dão pouco mais de 5 Sprints; por 30, 6 Sprints; por 25, pouco mais de 7 Sprints.
- Comunique a faixa, não a data única. "Entre 6 e 8 Sprints, ou seja, entre 12 e 16 semanas, se o escopo não mudar."
- Atualize a cada Sprint Review. Com o burnup, a cada Sprint a faixa se estreita e qualquer aumento de escopo aparece como uma subida na linha total.
Arredondar para cima é uma escolha consciente: um backlog que exige 5,3 Sprints de trabalho precisa de seis para terminar. Esse jeito de projetar é mais honesto do que prometer uma data com base na melhor Sprint. Ele também facilita a conversa sobre escopo: se a data é fixa, o Product Owner pode mostrar quais itens cabem e quais ficam para depois. Quando o projeto acompanha riscos com o mesmo raciocínio, o risk burndown mostra a exposição caindo Sprint a Sprint.
Erros que tiram o valor do gráfico
- Atualizar só na véspera da Review. O gráfico serve para decidir durante a Sprint. Atualizado no fim, só documenta o que já aconteceu.
- Queimar tarefas em vez de itens. O time conclui 80% das tarefas e nenhum item fica pronto. O gráfico parece ótimo e a Review não tem o que mostrar.
- Esconder mudança de escopo. Item novo entra e um antigo sai sem registro. A linha fica limpa e a informação some.
- Usar o gráfico para avaliar pessoas. O resultado é estimativa inflada e itens fatiados para parecer progresso.
- Ignorar a Meta da Sprint. Uma linha que chega a zero não significa que a meta foi alcançada. O que importa é o objetivo, não a soma dos pontos.
O que fazer na próxima Sprint
Comece pelo básico: escolha a unidade, combine que só item pronto queima e coloque o gráfico na tela da Daily. Depois de três Sprints, calcule a faixa de velocidade e use-a na próxima conversa sobre prazo. Se o escopo muda muito, troque o burndown da entrega por um burnup. O guia completo de métodos ágeis e Scrum mostra como essas práticas se encaixam nos eventos e artefatos do framework.
Para transformar esses dados em um painel que o time e o patrocinador entendam de relance, o curso Dashboard aplicado a projetos da Projeto Diário ensina a montar indicadores visuais de acompanhamento, do burndown ao status consolidado do portfólio.
