Para estimar story points, escolha primeiro uma história de referência que o time conhece, atribua a ela um valor e compare cada novo item por três lentes: quantidade de trabalho, complexidade e incerteza. Depois, cada pessoa escolhe uma carta sem ver as demais; o time revela os votos ao mesmo tempo, discute diferenças relevantes e registra uma estimativa que consiga explicar.
O número não é uma conversão de dias nem uma nota de desempenho. Ele expressa o tamanho relativo de um item dentro do contexto daquele time. Ao terminar este guia, você poderá montar referências, facilitar uma rodada e saber quando a história ainda não está pronta para ser estimada.
O que story points medem — e o que não medem
Story points são uma unidade abstrata para comparar o esforço relativo entre itens do backlog. Uma recomendação prática, descrita por Mike Cohn no guia de estimativa relativa, é considerar três fatores em conjunto:
- Quantidade de trabalho: quantas partes precisam ser construídas, testadas, revisadas e integradas?
- Complexidade: quão difícil é executar o trabalho corretamente?
- Risco e incerteza: quanto ainda não sabemos sobre requisitos, tecnologia ou dependências?
O Scrum Guide oficial em português diz que os itens do Product Backlog adquirem atributos como descrição, ordem e tamanho, e atribui o dimensionamento aos Developers que realizarão o trabalho. Interpretação prática: Scrum exige transparência suficiente sobre o tamanho, mas não obriga sua equipe a usar story points, Fibonacci ou Planning Poker.
Story points não são horas disfarçadas
Se o time define “1 ponto = 1 dia”, o ponto deixa de ser relativo e herda todos os problemas de uma promessa de prazo. Pessoas diferentes podem gastar tempos diferentes na mesma história e, ainda assim, concordar que ela é aproximadamente duas vezes maior que outra.
| Story points | Horas ou dias |
|---|---|
| Comparam o tamanho de itens dentro do mesmo contexto | Estimam duração no calendário |
| Combinam trabalho, complexidade e incerteza | Dependem mais diretamente de capacidade e disponibilidade |
| Funcionam com histórias de referência | Precisam de uma hipótese explícita de tempo |
| Não devem ser convertidos por uma taxa fixa | Podem ser úteis para tarefas curtas já compreendidas |
Os dois formatos podem existir no mesmo processo, desde que respondam a perguntas diferentes. Pontos ajudam a comparar itens do Product Backlog; horas podem ajudar a organizar trabalho detalhado quando o time já conhece a solução.
Prepare a escala antes da votação
Uma tabela universal de story points não funciona porque 5 pontos não representam o mesmo trabalho para todas as equipes. A escala precisa de referências locais, preferencialmente histórias concluídas recentemente e entendidas por quem está estimando.
Comece com três âncoras:
| Referência | Leitura relativa | Exemplo do mesmo produto |
|---|---|---|
| 2 pontos | Pequena, conhecida e com pouca incerteza | Alterar um texto e validar a exibição em dois estados existentes |
| 5 pontos | Média, com mais de uma camada ou cenário relevante | Adicionar um campo opcional usando validação e persistência já existentes |
| 8 pontos | Grande ou incerta o bastante para exigir conversa | Integrar um novo provedor com falhas, retentativas e observabilidade |
Esses exemplos não são uma regra de mercado. Eles mostram como um time hipotético pode construir sua régua. Se a realidade mudar — nova arquitetura, equipe diferente ou referências antigas — recalibre as âncoras.
Como estimar story points em cinco passos
1. Apresente uma história estimável
Explique o objetivo do usuário, os critérios de aceite, as restrições e a definição de pronto relevante. Não detalhe uma solução para induzir um número. Se faltarem informações essenciais, use ?, registre a pergunta e resolva a lacuna antes de pedir precisão.
Uma história pronta para a conversa não precisa ter todas as decisões técnicas tomadas, mas o time deve entender o resultado esperado e conseguir identificar o trabalho principal.
2. Compare com as referências
Pergunte, nesta ordem:
- Há mais ou menos trabalho que na história de 5 pontos?
- A solução é mais complexa ou apenas maior?
- Existe uma dependência, risco ou área desconhecida que muda a comparação?
- A história cabe como uma unidade coerente ou deveria ser dividida?
Evite começar com “quantos dias isso leva?”. A pergunta relativa reduz a pressão por uma exatidão que ainda não existe.
3. Escolha a carta individualmente
Cada pessoa que participa da entrega seleciona a carta que melhor representa sua comparação. No Planning Poker, essa escolha permanece secreta até que todos estejam prontos. A revelação simultânea reduz o efeito de ancoragem do primeiro número ou da opinião mais influente.
4. Revele, investigue e vote de novo quando necessário
A Agile Alliance descreve o Planning Poker como uma dinâmica em que as estimativas alta e baixa explicam seus raciocínios antes de novas rodadas. O objetivo não é defender cartas; é compartilhar premissas.
Se aparecerem 3, 5, 5 e 8, pergunte o que a pessoa do 3 deixou fora e qual risco levou ao 8. Atualize a história quando a conversa revelar informação nova. Só então faça outra rodada.
5. Registre a decisão e calibre depois
Registre a estimativa acordada junto da história, mas preserve também o aprendizado: uma dependência descoberta, um critério de aceite adicionado ou uma razão para dividir o item. Quando o trabalho terminar, compare a história com as referências — sem transformar a revisão em cobrança individual.
A Atlassian recomenda calibrar estimativas regularmente, usando histórias anteriores e retrospectivas para manter consistência. A recomendação útil aqui é revisar a régua, não alterar pontos depois da entrega apenas para fazer o histórico parecer preciso.
Exemplo completo: aplicar cupom no carrinho
Uma equipe de e-commerce estima a história: “Como cliente, quero aplicar um cupom no carrinho para ver o desconto antes de pagar.”
Os critérios de aceite dizem que o cupom pode ser válido, expirado, já utilizado ou incompatível com a categoria do produto. A API de promoções já existe e tem documentação. O componente de resumo do carrinho também existe.
O time usa duas referências recentes:
- 3 pontos: adicionar um campo de CPF opcional usando os padrões já existentes;
- 8 pontos: integrar um novo meio de pagamento, com webhook, retentativa e conciliação.
Na comparação, a história do cupom tem mais cenários e integração que a referência de 3, mas não cria um provedor nem um fluxo assíncrono como a de 8. Os votos iniciais são 3, 5, 5 e 8.
A pessoa do 3 considerou apenas o caminho feliz. A pessoa do 8 incluiu uma regra de acumular vários cupons, mas o Product Owner esclarece que apenas um cupom será aceito. O time acrescenta um critério para remover o desconto quando os itens do carrinho mudarem e vota novamente: 5, 5, 5, 5.
O valor 5 não veio de uma fórmula. Ele veio de uma comparação explicável com referências compartilhadas e de uma conversa que corrigiu duas interpretações de escopo.
Três cenários para decidir com responsabilidade
Cenário feliz: as referências ainda representam o trabalho
As histórias-base são recentes, todos conhecem a definição de pronto e a primeira votação fica próxima. O time esclarece uma pequena diferença, registra 5 e segue. A estimativa foi rápida porque a calibração aconteceu antes da reunião.
Cenário de falha: a empresa exige “um ponto por dia”
Uma liderança compara 20 pontos de uma equipe com 35 de outra e conclui que a segunda produz mais. A comparação é inválida: cada grupo tem referências, contexto e composição próprios. Separe previsão de entrega de avaliação de desempenho e não normalize escalas para montar um ranking.
Cenário alternativo: a história depende de uma API desconhecida
Ninguém sabe se o fornecedor permite a operação necessária. Em vez de escolher 13 “por segurança”, o time usa ?, registra a dúvida e cria uma investigação limitada. A estimativa acontece depois que a incerteza decisiva diminui; se o item continuar grande, ele é dividido.
Erros comuns ao estimar story points
Copiar uma tabela pronta da internet
Uma lista que diz “login = 3” e “relatório = 8” ignora arquitetura, qualidade exigida e conhecimento da equipe. Use tabelas para documentar referências locais, não para importar valores universais.
Estimar pessoas em vez de trabalho
“Para a pessoa sênior é 3; para a júnior é 8” transforma a conversa em alocação individual. Compare o item com outras histórias considerando a equipe que normalmente entrega o produto.
Somar complexidade, esforço e risco como fórmula
Dar notas separadas e somar 2 + 3 + 3 = 8 cria aparência de ciência sem eliminar julgamento. Use os três fatores como perguntas para comparação, não como parcelas obrigatórias.
Aceitar a média automaticamente
Cartas 3 e 13 produzem média 8, mas podem esconder escopos incompatíveis. Antes de registrar qualquer valor, descubra por que as pessoas enxergaram trabalhos diferentes. O guia sobre divergência de votos no Planning Poker traz um roteiro específico para essa conversa.
Manter referências obsoletas
Uma história de dois anos atrás pode ter sido feita em outra arquitetura ou por outra composição de equipe. Revise as âncoras quando o contexto mudar e prefira exemplos concluídos que todos consigam explicar.
Checklist antes de estimar
- O objetivo do usuário e os critérios de aceite estão claros.
- A definição de pronto considerada é a mesma para todos.
- Há pelo menos uma história de referência conhecida pelo time.
- A comparação inclui trabalho, complexidade e incerteza.
- As cartas serão escolhidas sem revelar o voto antes da hora.
- O facilitador sabe como tratar divergências sem calcular a média automaticamente.
- Existe permissão para usar
?, dividir ou adiar um item incompleto. - A estimativa e os aprendizados da conversa serão registrados.
Se a equipe ainda precisa aprender a dinâmica completa, comece pelo guia O que é Planning Poker. Para dúvidas rápidas sobre cartas, participantes e revelação, consulte a FAQ do Battle Poker.
Perguntas frequentes
Qual número deve ser a primeira história de referência?
Não existe um valor obrigatório. 2, 3 ou 5 funcionam se deixarem espaço para histórias menores e maiores. O essencial é que o time conheça a referência e consiga explicar por que outros itens são menores, semelhantes ou maiores.
Quanto tempo vale um story point?
Não há conversão fixa. O tempo observado pode ajudar a prever entregas no contexto da própria equipe, mas transformar pontos em uma taxa universal elimina a comparação relativa e cria uma promessa artificial.
É melhor usar Fibonacci ou tamanhos de camiseta?
Fibonacci facilita decisões em uma escala numérica com intervalos crescentes. Tamanhos como P, M e G podem ser mais rápidos para agrupar muitos itens ainda pouco detalhados. Escolha a escala conforme a decisão necessária e mantenha referências claras.
Product Owner e Scrum Master votam?
Quem realizará o trabalho é responsável pelo dimensionamento. O Product Owner contribui esclarecendo valor, escopo e trade-offs; o Scrum Master pode facilitar o processo. A composição exata deve preservar a autonomia de quem entrega e evitar votos que apenas representem pressão de prazo.
O time precisa chegar ao mesmo número em todas as cartas?
Não. O objetivo é chegar a uma decisão compreendida, não produzir unanimidade visual a qualquer custo. Uma diferença pode levar a uma nova rodada, divisão da história, investigação ou adiamento.
Conclusão: pontos úteis são comparações explicáveis
Uma boa estimativa não nasce de uma tabela universal. Ela nasce de histórias de referência, critérios comuns e uma conversa que torna trabalho e incerteza visíveis. Prepare o item, compare, vote sem ancoragem, investigue diferenças e atualize a régua com responsabilidade.
No Battle Poker, você pode criar uma sala sem cadastro, compartilhar o link e manter as cartas ocultas até a revelação simultânea. Depois, revise a distribuição dos votos, registre a estimativa acordada e preserve o histórico da rodada.
