TeamBOX
Sprints e entrega

A sprint vai ser entregue? Métricas que avisam a tempo

Métricas de sprint que avisam antes do atraso: termômetro de pontos × tempo, burndown, WIP alto e bloqueios — e o que fazer quando a entrega está em risco.

11 min de leitura · Publicado em · Atualizado em

O que são métricas de sprint e por que acompanhar durante — não depois

Métricas de sprint são os indicadores que mostram, ao longo do ciclo, se o trabalho planejado vai ser concluído dentro do prazo combinado. As mais úteis comparam duas grandezas simples: quanto do tempo da sprint já passou e quanto do trabalho (medido em pontos ou itens) já foi de fato concluído. Quando essas duas curvas andam juntas, a entrega está no rumo; quando o tempo corre mais rápido que a conclusão, a sprint está em risco — e quanto antes o gestor perceber, mais opções ele tem.

A diferença entre acompanhar durante e descobrir no final é a diferença entre corrigir e lamentar. No último dia da sprint, não há mais decisão a tomar: o que não foi entregue, não foi. No meio da sprint, ainda dá para repriorizar, tirar escopo, destravar um bloqueio ou pedir ajuda. Por isso as métricas que importam para o gestor são as preditivas — as que avisam a tempo —, e não apenas as retrospectivas, como a velocidade média, que só se revelam quando o ciclo termina.

Isso vale para qualquer área, não só para tecnologia. Um time de marketing rodando uma sprint de duas semanas para lançar uma campanha, um time de RH estruturando um novo processo de onboarding ou um time de produto preparando uma release enfrentam o mesmo dilema: como saber, na terça-feira da segunda semana, se a sexta vai terminar em entrega ou em desculpa. Se você ainda está montando seus primeiros ciclos, vale começar pelo básico em o que é uma sprint e voltar aqui quando o time já tiver um board rodando.

O termômetro da sprint: % do tempo × % dos pontos

A métrica mais direta — e a que mais recomendo para quem gerencia sem viver dentro do board — é a comparação entre percentual do tempo decorrido e percentual dos pontos concluídos. A lógica é de regra de três: se a sprint tem 10 dias úteis e estamos no fim do dia 5, passaram 50% do tempo; se o time planejou 40 pontos e concluiu 12, foram 30% dos pontos. A conta fecha em um diagnóstico imediato: o time está 20 pontos percentuais atrás do relógio.

Esse "termômetro" tem três leituras possíveis:

  • Conclusão ≥ tempo: a sprint está saudável. O time concluiu proporcionalmente mais do que o tempo que passou.
  • Conclusão um pouco abaixo do tempo (até ~10 pontos percentuais): atenção. Normal no meio da sprint, porque itens grandes tendem a concluir em bloco, mas vale conferir se há bloqueio se formando.
  • Conclusão muito abaixo do tempo: risco real. Se 70% do tempo passou e só 35% dos pontos foram concluídos, a matemática não fecha mais com boa vontade — fecha com decisão.

Um exemplo fora da TI: a equipe de conteúdo da Renata planejou 30 pontos para uma sprint de duas semanas — artigos, roteiros de vídeo e a revisão de um e-book. Na segunda quinta-feira (80% do tempo), o board mostrava 12 pontos concluídos (40%). Sem o termômetro, a sensação do time era "estamos quase lá, tem muita coisa em andamento". Com o termômetro, a conversa mudou: "em andamento" não é entregue, e faltavam 18 pontos para dois dias. Renata cortou o e-book da sprint na hora, com o time, e os artigos da campanha saíram no prazo.

Duas ressalvas para usar bem essa métrica. Primeiro, ela depende de estimativa razoável — se o time ainda não estima, comece por como estimar com story points, porque contar itens de tamanhos muito diferentes distorce a leitura. Segundo, só conte pontos de itens concluídos de verdade (na coluna final do board), nunca "quase prontos". Item 90% pronto contribui com 0% para o termômetro — e essa dureza é justamente o que torna a métrica confiável.

No TeamBOX, esse cálculo é o termômetro da sprint: a plataforma cruza a meta de pontos com o tempo decorrido e o que já foi entregue, e dispara um alerta só para o gestor quando a conclusão descola do relógio. O detalhe do alerta privado importa: o objetivo é dar ao gestor tempo de agir e conversar, não expor o time num painel vermelho que gera ansiedade antes de gerar solução.

O burndown: a forma da curva conta a história

O gráfico de burndown é o irmão visual do termômetro: uma linha que parte do total de pontos planejados e desce a cada conclusão, comparada com uma linha ideal que desce em ritmo constante até zero no último dia. Mais do que a posição da linha, o que informa é a forma dela:

  • Linha reta colada na ideal: ritmo saudável, itens concluindo com frequência.
  • Platô (linha andando de lado): dias se passando sem nenhuma conclusão. É o padrão mais perigoso, porque costuma indicar itens grandes demais, bloqueio ou trabalho invisível (coisas sendo feitas fora do board).
  • Despenca tudo no fim: o time "entrega" a sprint inteira nos últimos dois dias. Tecnicamente fechou, mas sem previsibilidade nenhuma durante o ciclo — e provavelmente com teste e revisão espremidos.
  • Linha que sobe: escopo entrando no meio da sprint. Cada subida merece uma pergunta: quem adicionou, por quê, e o que saiu para compensar?

O burndown funciona melhor como pauta de conversa do que como ferramenta de cobrança. Um platô de três dias na daily não é motivo para bronca — é motivo para a pergunta "o que está impedindo a gente de concluir alguma coisa hoje?".

Os sinais que o gráfico não mostra: dependência externa e WIP alto

Duas situações minam a sprint por baixo, antes de aparecerem em qualquer curva.

Itens parados em dependência externa

Todo time depende de alguém de fora: o jurídico que precisa aprovar a peça, o fornecedor que não mandou o orçamento, a outra área que não liberou o acesso. O problema não é a dependência existir — é ela ficar invisível. Um item parado esperando terceiros parece "em andamento" no board e conta como esforço na cabeça de todo mundo, mas não anda um centímetro.

A prática que resolve é dar a esses itens uma coluna própria no board (no TeamBOX, a coluna Dependência externa existe exatamente para isso) e olhar essa coluna como métrica: quantos itens estão parados esperando terceiros, e há quantos dias? Um item parado por um dia é vida real; três itens parados há quatro dias são um quarto da sprint sequestrado — e destravá-los é trabalho do gestor, não do time. No time de RH do Fábio, a sprint de reformulação do onboarding travou porque dois itens esperavam validação do jurídico havia uma semana. O time não podia fazer nada; Fábio, com uma ligação de dez minutos, podia. A métrica só fez o problema sair da conversa de corredor e entrar na gestão.

WIP alto: muita coisa começada, pouca coisa terminada

WIP (work in progress) é a quantidade de itens em andamento ao mesmo tempo. Quando um time de cinco pessoas tem doze itens abertos, ninguém está terminando nada — todo mundo está começando tudo. O sintoma clássico é o time se sentir exausto e ocupado enquanto o burndown anda de lado: esforço alto, conclusão baixa, porque cada troca de contexto cobra pedágio de retrabalho e reaprendizado.

A regra prática vem do kanban: pare de começar, comece a terminar. Como métrica de acompanhamento, um bom termômetro é o WIP não passar muito do número de pessoas do time. Se passou, a pergunta da daily muda de "o que você vai fazer hoje?" para "qual item a gente fecha hoje, juntos?". Duas pessoas terminando um item valem mais do que duas pessoas abrindo dois.

Planejado × meta × entregue: a tríade da meta de pontos

Ao fechar cada sprint, três números merecem registro — e a comparação entre eles diz mais do que qualquer um isolado:

  1. Planejado: quantos pontos o time colocou na sprint na planning.
  2. Meta: quantos pontos o time se comprometeu a entregar — que pode ser menor que o planejado, quando o time embarca itens "se der tempo".
  3. Entregue: quantos pontos de fato cruzaram a linha de concluído.

Sprint após sprint, os padrões aparecem. Se o entregue fica sistematicamente abaixo do planejado, o time está planejando com otimismo crônico — o ajuste acontece na próxima planning, reduzindo o escopo até a conta fechar, e não pedindo mais horas de esforço. Se entregue e planejado batem sempre com folga, talvez o time esteja subestimando a própria capacidade e caiba um desafio maior. E se os números oscilam violentamente (110% numa sprint, 40% na outra), o problema costuma ser estimativa inconsistente ou interrupções externas descontroladas — assunto para a retrospectiva, não para cobrança individual.

Distinguir meta de planejado tem um efeito colateral saudável: cria espaço honesto para itens opcionais. O time da Priscila, de produto, planeja em média 45 pontos com meta de 38 — os 7 pontos de diferença são melhorias que entram se a sprint correr bem. Quando não entram, ninguém "falhou": a meta foi batida e os opcionais voltam ao backlog para disputar prioridade de novo.

Atrasou: o que fazer (e o que nunca fazer)

O termômetro acendeu no meio da sprint. O que agora? Três movimentos legítimos, em ordem de preferência:

1. Repriorizar dentro da sprint. Antes de cortar qualquer coisa, garanta que o time está terminando primeiro o que mais importa. É comum descobrir que o item mais valioso da sprint está esperando enquanto o time avança em três itens confortáveis. Reordene: o que tem mais valor conclui primeiro; se algo vai sobrar, que sobre o menos importante.

2. Reduzir escopo — explicitamente. Se a matemática não fecha nem repriorizando, algo sai da sprint. A palavra-chave é explicitamente: o item volta ao backlog em uma conversa com o time (e com quem esperava a entrega), com registro claro do que saiu e por quê. Cortar escopo às claras é gestão madura; deixar o item morrer no board sem que ninguém anuncie é o começo da erosão de confiança.

3. Atacar o bloqueio pessoalmente. Se o atraso vem de dependência externa, o movimento não é apertar o time — é o gestor subir a escada: ligar, escalar, negociar prazo com a outra área. Muitas sprints "atrasadas" são, na verdade, sprints bloqueadas, e a alavanca está na mão de quem gerencia.

E o que nunca fazer: esticar a sprint silenciosamente. "Vamos só até quarta para fechar essas pendências" parece inofensivo, mas quebra o que a sprint existe para proteger: a previsibilidade do ritmo, a honestidade das métricas (uma sprint esticada "entrega 100%" de mentira) e a pressão saudável que força decisões de escopo. Sprint tem prazo fixo; o que varia é o escopo. Quando o prazo vira elástico, as estimativas param de significar qualquer coisa — e na sprint seguinte o time planeja pior, porque aprendeu que o prazo negocia.

Também não vale a variante simpática do mesmo erro: empurrar o item automaticamente para a próxima sprint. Item não concluído volta ao backlog e disputa lugar de novo na planning. Às vezes ele volta mesmo; às vezes, com uma semana de distância, descobre-se que nem era tão urgente.

Erros comuns ao acompanhar métricas de sprint

  • Contar "quase pronto" como pronto. Se o item não está na coluna final, ele vale zero. Sem essa dureza, o termômetro vira enfeite.
  • Usar métrica para ranquear pessoas. Pontos medem o fluxo do time, não o desempenho de indivíduos. No minuto em que viram avaliação individual, as estimativas incham e todas as métricas apodrecem.
  • Olhar só no fim. Velocidade e percentual de entrega são retrovisores. O valor está no meio da sprint, quando ainda há decisão possível.
  • Reagir a um dia ruim. Um dia de platô no burndown é ruído; três dias são sinal. Aja sobre tendências, não sobre flutuações.
  • Esconder o atraso do time. O alerta chega primeiro ao gestor, mas a correção é coletiva. Termômetro vermelho tratado em segredo vira microgerenciamento; tratado às claras, vira repriorização conjunta.
  • Ignorar a coluna de dependência externa. É onde as sprints morrem em silêncio. Olhe todos os dias.

Checklist do gestor durante a sprint

Um roteiro de cinco minutos, duas ou três vezes por semana:

  1. % do tempo × % dos pontos: a conclusão está acompanhando o relógio? Diferença acima de ~10 pontos percentuais na segunda metade da sprint pede ação, não observação.
  2. Forma do burndown: a linha desceu nos últimos dois dias? Platô de três dias exige conversa hoje.
  3. Dependências externas: quantos itens parados, há quantos dias, e qual ligação eu preciso fazer?
  4. WIP: há mais itens em andamento do que pessoas no time? Se sim, a pauta da próxima daily é "o que fechamos juntos hoje".
  5. Escopo: entrou algo na sprint que não estava na planning? O que saiu para compensar?
  6. Se o termômetro acendeu: repriorizar → reduzir escopo às claras → atacar bloqueio. Nunca esticar o prazo em silêncio.

Com esse hábito, a pergunta "a sprint vai ser entregue?" deixa de ser respondida na sexta-feira com um suspiro — e passa a ser respondida na terça, com tempo de sobra para mudar a resposta.

Perguntas frequentes

Como saber se a sprint vai ser entregue antes do último dia?

Compare o percentual do tempo decorrido com o percentual de pontos concluídos. Se 60% do tempo já passou e o time concluiu só 30% dos pontos, a sprint está em risco e ainda dá tempo de agir. Complemente com o burndown, a contagem de itens parados em dependência externa e o volume de trabalho em andamento (WIP).

O que fazer quando a sprint está atrasada?

Três movimentos funcionam: repriorizar (garantir que o time termine primeiro o que tem mais valor), reduzir escopo (devolver itens ao backlog de forma explícita e combinada) e atacar bloqueios (o gestor assumir pessoalmente a cobrança de dependências externas). O que não funciona é esticar o prazo em silêncio — isso destrói a confiança nas estimativas.

Quais métricas acompanhar durante a sprint, e não só no final?

As quatro que avisam a tempo são: percentual de pontos concluídos versus percentual do tempo decorrido, o gráfico de burndown, a quantidade de itens parados em dependência externa e o WIP (itens em andamento ao mesmo tempo). Velocidade e percentual de entrega são úteis, mas só se revelam quando a sprint acaba.

Pode esticar o prazo da sprint quando o time não termina tudo?

Não é recomendado. A sprint tem duração fixa justamente para forçar decisões de escopo e manter o ritmo previsível. O que não foi concluído volta ao backlog e é repriorizado na próxima planning. Esticar o prazo esconde o problema real — que costuma ser excesso de escopo, estimativa otimista ou bloqueio não tratado.

Qual é um bom percentual de entrega de sprint?

Times saudáveis costumam concluir a maior parte do que planejaram na maioria das sprints, sem precisar de heroísmo no último dia. Mais importante que perseguir 100% é a consistência: entregar 80% de forma previsível vale mais do que alternar entre 110% e 40%. Se o time entrega sempre muito menos do que planeja, o problema está no planejamento, não na execução.

Leia também

Coloque isso em prática no TeamBOX

No TeamBOX, gestor e liderado fazem a 1:1 no mesmo tabuleiro — pauta, feedbacks, PDI e histórico num só lugar.

Começar grátis →