Planning poker e story points: como estimar no ágil
O Product Owner quer saber se a nova funcionalidade cabe na próxima entrega, e o time responde com um "depende" que não ajuda ninguém. Estimar em horas também não resolve: cada pessoa calcula de um jeito, ninguém considera as interrupções e o número vira cobrança. O planning poker existe para esse impasse. É uma técnica de estimativa em grupo em que o time compara itens do backlog entre si e atribui a cada um um tamanho relativo, geralmente em story points.
A técnica foi descrita por James Grenning em 2002 e ganhou popularidade com o livro Agile Estimating and Planning, de Mike Cohn, publicado em 2005. A ideia central é simples: pessoas erram muito ao prever quanto tempo algo leva, mas acertam bem mais ao dizer que uma tarefa é "mais ou menos o dobro" de outra.
Abaixo está o passo a passo para conduzir uma sessão, o que os pontos medem e como usar o resultado para prever entregas sem transformar a estimativa em meta de produtividade.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que são story points e o que eles medem
Story point (ponto de história) é uma unidade sem dimensão que expressa o tamanho de um item do backlog em relação a outros itens. Ele junta três fatores numa única nota:
- Volume de trabalho: quantas telas, regras, documentos ou integrações o item envolve.
- Complexidade: quão difícil é resolver, mesmo que o volume seja pequeno.
- Incerteza: quanto o time ainda não sabe (uma API nunca usada, uma regra de negócio indefinida, um fornecedor novo).
O ponto não mede horas nem o esforço de uma pessoa específica. Um item de 5 pontos não é "5 dias": é algo que o time considera mais ou menos o dobro de um item de 2 pontos e bem menor que um de 13. Por isso a estimativa relativa funciona mesmo quando as pessoas têm velocidades individuais diferentes.
A escala mais usada é a sequência de Fibonacci modificada: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 e 100, além de cartas como "?" (não sei estimar) e a xícara de café (preciso de uma pausa). Os intervalos crescem de propósito. Para itens grandes, a precisão cai, e discutir se algo vale 14 ou 15 é perda de tempo.
Antes da sessão: o que preparar
O planning poker dá errado quando o time tenta estimar algo que ninguém entende. Antes de marcar a sessão, confira quatro pontos:
- Itens refinados. Cada item tem descrição clara e critérios de aceitação. Se a conversa durante a votação for sobre o que o item é, e não sobre o tamanho dele, falta refinamento. O refinamento do backlog, feito ao longo da Sprint anterior, é o momento de preparar os itens.
- Product Owner presente. Ele explica o valor e responde às dúvidas de negócio. Não vota.
- História de referência. Escolha um item já entregue que todo mundo conhece e que seja pequeno, mas não trivial. Ele recebe 2 ou 3 pontos e vira a régua de comparação.
- Baralho. Cartas físicas, um aplicativo de planning poker ou um recurso da ferramenta de backlog (Jira e Azure DevOps têm extensões para isso). Em times remotos, o importante é que a revelação seja simultânea.
Como fazer planning poker: passo a passo
Uma sessão típica leva de 45 minutos a 1h30, dependendo da quantidade de itens. Siga esta sequência para cada item:
- Apresentação. O Product Owner lê o item e explica por que ele importa. Até dois minutos.
- Perguntas. Os Developers tiram dúvidas sobre regras, dependências e critérios de aceitação. O facilitador corta discussões de solução técnica detalhada, que cabem depois.
- Escolha individual. Cada pessoa compara o item com a história de referência e escolhe uma carta, sem mostrar.
- Revelação simultânea. Todos viram a carta ao mesmo tempo. Esse detalhe evita a ancoragem: quando a pessoa mais experiente fala primeiro, os outros tendem a repetir o número dela.
- Discussão dos extremos. Se os valores divergem (um 3 e um 13, por exemplo), quem deu o menor e quem deu o maior explicam o raciocínio. Quase sempre um dos dois sabe algo que os outros não sabem: uma integração esquecida, um componente que já existe.
- Nova rodada. O time vota de novo. Em geral, duas ou três rodadas bastam para convergir.
- Registro. Anote o valor no item. Se depois de três rodadas ainda houver divergência, adote o valor maior ou marque o item para mais refinamento.
- Quebra dos grandes. Na maioria dos times, item que recebe 20 pontos ou mais é grande demais para caber com folga numa Sprint. Devolva ao Product Owner para dividir em partes menores (dá para quebrar por regra de negócio, por tipo de usuário ou por etapa do fluxo).
Exemplo ilustrativo: sistema de chamados
Imagine um time que desenvolve um sistema de abertura de chamados para a área de manutenção de uma prefeitura. A história de referência, já entregue, é "cadastrar tipo de chamado", com 2 pontos.
| Item | Votos na 1ª rodada | O que surgiu na discussão | Valor final |
|---|---|---|---|
| Anexar foto ao chamado | 2, 3, 3, 8 | Quem votou 8 lembrou que o armazenamento de arquivos ainda não existe no sistema | 5 |
| Filtrar chamados por bairro | 2, 2, 3, 2 | Consenso rápido, campo já existe no banco | 2 |
| Enviar aviso por e-mail ao solicitante | 3, 5, 5, 13 | A pessoa do 13 sabia que o servidor de e-mail da prefeitura exige homologação de segurança | 8, com um item separado para a homologação |
Repare que o valor do planning poker apareceu nas divergências: duas informações críticas só vieram à tona porque alguém votou diferente.
Como usar os pontos para prever entregas
Os pontos só viram previsão quando o time conhece a própria velocidade: a soma dos pontos dos itens que atenderam à Definição de Pronto em cada Sprint. Itens incompletos não contam.
Depois de três ou quatro Sprints, use uma faixa, e não uma média única. Se o time entregou 21, 26, 18 e 24 pontos, a previsão honesta é "entre 18 e 26 por Sprint". Com 120 pontos no backlog de uma release, isso significa algo entre cinco e sete Sprints. Uma faixa assim é mais útil para o patrocinador do que uma data exata que todos sabem que vai mudar.
O acompanhamento dessa previsão ao longo do tempo é feito com gráficos de burndown e burnup, explicados no artigo sobre burndown e velocidade do time. Na Sprint Planning, a velocidade recente serve de referência para o quanto selecionar, mas a decisão final é dos Developers, que consideram férias, feriados e a Meta da Sprint.
Erros que distorcem a estimativa
- Converter ponto em hora. Quando a gestão define que "1 ponto = 4 horas", o time volta a estimar em horas com outro nome e perde a comparação relativa.
- Comparar velocidade entre times. Cada time tem a sua régua. Um time que entrega 40 pontos não é mais produtivo que outro que entrega 20; só usa uma escala diferente.
- Transformar velocidade em meta. Se o número vira cobrança, os pontos inflam em poucas Sprints e deixam de servir para prever.
- Product Owner ou gestor votando. Quem não faz o trabalho tende a puxar a estimativa para baixo. O papel deles é explicar, não estimar.
- Estimar sem a história de referência. Sem régua, cada sessão usa um tamanho diferente e o histórico perde valor.
- Reestimar itens já concluídos. Se o item de 3 pontos deu muito mais trabalho, discuta isso na retrospectiva e calibre as próximas estimativas, mas não reescreva o passado para "acertar" a velocidade.
Planning poker é obrigatório no Scrum?
Não. O Guia do Scrum fala em dimensionamento dos itens do Product Backlog como parte do refinamento e deixa a técnica a cargo dos Developers. Planning poker e story points são práticas complementares, populares em times Scrum, mas não fazem parte do framework (o artigo o que é Scrum mostra o que é e o que não é obrigatório).
Alternativas que funcionam bem:
- Tamanhos de camiseta (P, M, G, GG): bons para estimar épicos e roadmap, quando não faz sentido discutir números.
- Estimativa por afinidade: o time distribui dezenas de cartões numa parede, do menor ao maior, em silêncio, e depois ajusta. Serve para estimar um backlog inteiro em uma hora.
- Contagem de itens: quando o time quebra tudo em itens de tamanho parecido, contar quantos foram entregues por Sprint prevê tão bem quanto somar pontos.
A escolha depende do que o time precisa responder. Para decidir o que cabe na Sprint, qualquer uma serve. Para prever uma release com meses de trabalho, a combinação de pontos e velocidade histórica costuma ser a mais usada.
Quando o patrocinador exige uma data
Em muitos projetos, sobretudo os que têm contrato, edital ou lançamento marcado, a pergunta não é "quantos pontos" e sim "em que dia". Nesses casos, os story points ajudam a medir o backlog, e uma técnica probabilística ajuda a traduzir esse tamanho em datas com grau de confiança. O artigo sobre estimativa em projetos com alta incerteza compara os métodos disponíveis, e o guia completo de métodos ágeis e Scrum mostra onde a estimativa entra no ciclo ágil.
Para começar já na próxima Sprint, escolha a história de referência com o time, estime os dez primeiros itens do backlog e registre a velocidade das próximas três Sprints antes de prometer qualquer data. Quando precisar responder ao patrocinador sobre o prazo de uma entrega maior, a calculadora PERT com Monte Carlo da Projeto Diário roda milhares de simulações a partir de estimativas otimista, provável e pessimista e mostra a chance de cumprir cada data.
