Estimativa ágil: guia completo para times Scrum

O que é estimativa ágil (e por que não é prometer data)

Estimativa ágil é dimensionar o trabalho de forma relativa. Em vez de perguntar quantas horas um item vai levar, o time pergunta quanto ele é maior ou menor que outros itens que já conhece. O número que sai do ritual é uma leitura de esforço, complexidade e incerteza, não uma promessa de calendário.

O guia do Scrum, publicado em scrumguides.org, não prescreve técnica nem evento de estimativa. Ele diz que o refinamento do backlog adiciona detalhes como descrição, ordem e tamanho, e que quem executa o trabalho é responsável pelo dimensionamento. Estimar, portanto, é prática de apoio ao planejamento, não uma exigência do framework.

A confusão comum é tratar a estimativa como compromisso. Quando o número vira promessa de data, o time começa a inflar valores para se proteger e perde o que torna a estimativa útil: honestidade sobre o desconhecido. Prazo se responde com a velocidade do time, em faixa, como explica o guia de story points vs horas.

Estimativa relativa x absoluta

A estimativa absoluta tenta prever tempo de relógio: quatro horas, dois dias, uma semana. A relativa compara itens entre si: este é parecido com aquele, aquele outro é maior. Comparar é mais fácil que prever, porque quem compara tem referência concreta e quem prevê trabalha com suposição.

A unidade relativa mais usada é o story point, que não tem valor absoluto. Um item de 5 pontos equivale a outro item de 5 pontos do mesmo time, e nada mais que isso. Os detalhes da escala e a armadilha da conversão para horas estão no guia de story points vs horas.

Horas não são proibidas. Elas funcionam em trabalho repetível e conhecido, como quebra de uma história em tarefas ou manutenção com histórico. O erro é misturar as duas unidades no mesmo planejamento e acabar convertendo uma na outra para fechar conta de prazo.

As principais técnicas, lado a lado

Não existe técnica certa para todo momento. As três famílias abaixo cobrem a maior parte dos casos, e a escolha depende da fase do backlog e do que o time precisa decidir.

O ponto é a unidade relativa; o Fibonacci é a escala que cresce rápido para não forçar precisão onde ela não existe. A calibração com história de referência está no guia de story points, e os valores de cada faixa, no guia de Fibonacci.

T-shirt sizing troca números por tamanhos (PP, P, M, G, GG) e rende na triagem de backlog grande. O guia de t-shirt sizing mostra a escala e as tabelas de conversão para pontos.

Planning poker é o ritual de votação em grupo: voto secreto, reveal simultâneo e conversa nos extremos. Serve para qualquer escala, de pontos a tamanhos. O guia de como jogar percorre a sessão inteira, e o guia de scrum poker x planning poker esclarece os nomes.

Como uma estimativa nasce na prática

O ciclo abaixo vale para qualquer técnica. Cada time ajusta detalhes, mas a sequência raramente muda.

1. Refinar antes de estimar. O item chega com contexto e critérios de aceite. Dúvida de entendimento se resolve no refinamento, não na votação.
2. Comparar com referências. O time usa histórias já entregues como régua, como descreve o guia de story points.
3. Votar em segredo. Cada pessoa escolhe a carta sem ver o voto das outras. O voto simultâneo evita a ancoragem do primeiro número falado.
4. Revelar e discutir. Quem votou menos e quem votou mais explica primeiro. O guia de votos divergentes traz o roteiro completo dessa conversa.
5. Registrar o valor. O número combinado volta para o item no backlog, onde o time planeja. A sala do Pointly é efêmera e não guarda histórico, então o registro é responsabilidade do time.

A cadência importa mais que o formato. Estimar uma vez por sprint, com os itens que vão entrar na sprint seguinte, costuma bastar. Sessões extras só se justificam quando o backlog acumulou itens novos relevantes, e não como rotina.

Da estimativa à previsão: velocidade (sem converter em horas)

Com os números no backlog, o time soma os pontos concluídos a cada sprint. Essa série é a velocidade, e ela responde quanto cabe nas próximas sprints sem passar por horas.

Nas primeiras sprints, a faixa é larga e pouco confiável, e isso é normal. Recalibre conforme o histórico cresce e trate a velocidade como medida do time atual, não como número eterno: férias, entradas e saídas de pessoas e mudanças no produto deslocam a faixa.

A leitura é sempre em faixa. Se o time fechou entre 22 e 26 pontos nas últimas sprints, o próximo planejamento parte dessa faixa, não de uma meta exata. Converter a velocidade para horas reintroduz a falsa precisão que os pontos existem para evitar.

Velocidade serve para o time prever o próprio trabalho. Não serve para comparar times nem para avaliar pessoas, porque cada escala é local. Aprofunde em story points vs horas.

Erros comuns de quem está começando

• Converter pontos em horas. A taxa fixa quebra quando o time, o produto ou o tipo de item muda. Previsão sai da velocidade, em faixa.
• Estimar tudo. Nem bug urgente, nem tarefa operacional, nem investigação pedem voto. O critério é o que precisa de decisão de planejamento, como discute o guia de planning poker para devs.
• Tratar pontos como produtividade. Pontos medem o item, não a pessoa. Quando viram meta, inflam e perdem sentido.
• Trocar de escala toda sprint. A régua só acumula sentido com estabilidade. Trocar de escala reinicia o aprendizado do time.
• Estimar item grande demais. Item no teto da escala pede divisão, não votação repetida até alguém ceder.
• Pular o registro. Estimativa que morre na reunião não vira previsão nem calibração da régua.

Mapa de todos os guias do Pointly

Todos os guias publicados, com uma linha cada. Vá direto ao que a sua dúvida pede.

• Como jogar planning poker, passo a passo. O roteiro de uma sessão real: papéis, rodada a rodada, tempo por história e o que fazer quando os votos divergem.
• O que é planning poker?. De onde veio, por que o voto simultâneo funciona e quando usar o ritual — com um exemplo prático de rodada.
• Story points: o que são e como estimar. Escala, sequência de Fibonacci, story points vs horas e como calibrar a estimativa com uma história de referência.
• Planning poker remoto: estimar com time distribuído. Como rodar a sessão em videochamada sem ancoragem: agenda de 45 minutos, fusos horários e checklist de facilitação.
• Story points vs horas: como responder quando fica pronto. Por que não converter ponto em hora e como prever prazo com a velocidade do time, em faixa.
• Fibonacci na estimativa ágil: por que 1, 2, 3, 5, 8, 13. A sequência clássica e a modificada, o que cada faixa de valor significa e o que fazer quando a história chega a 13.
• T-shirt sizing: escala PP-GG e conversão em pontos. Estimativa por tamanhos para triagem de backlog, com tabelas de conversão para story points.
• Votos divergentes no planning poker: como conduzir a discussão. Roteiro de 5 passos para depois do reveal: quem fala primeiro, como perguntar e quando dividir a história.
• Planning poker para devs: bugs, spikes e tarefas técnicas. Como estimar bug, investigação com timebox e dívida técnica, com opções em vez de regra.
• Agenda de sessão de planning poker: modelo de 45 minutos. Papéis, blocos com tempo sugerido e checklist de antes, durante e depois da estimativa.
• Scrum poker x planning poker: qual é a diferença?. Os nomes da mesma técnica (pointing poker, pôquer de planejamento) e qual usar no seu time.
• Planning poker online grátis: comparativo. Pointly, Point Poker, SprintsPoker, Scrum Poker Online e Utilaria lado a lado: cadastro, limite de participantes, baralhos, anúncios e extras.

A lista completa com descrições também vive no hub de guias, e o comparativo de ferramentas ajuda a escolher onde votar.

Perguntas frequentes