Tecnicas de estimativa agil: alem do Planning Poker

Equipe de desenvolvedores reunidos em torno de um quadro branco coberto de notas adesivas coloridas organizadas em grupos, colaborando na estimativa do backlog do sprintEquipe de desenvolvedores reunidos em torno de um quadro branco coberto de notas adesivas coloridas organizadas em grupos, colaborando na estimativa do backlog do sprint O Planning Poker recebe a maior parte da atencao na estimativa agil, e com razao. Mas nao e a unica opcao. Dependendo do tamanho da sua equipe, do tipo de trabalho e de quanto tempo voce tem, outras tecnicas podem se encaixar melhor. Veja o que mais existe e quando usar cada uma.

Planning Poker (a referencia)

Se voce ja conhece o Planning Poker, sabe como funciona: a equipe discute um item do backlog, todos selecionam uma carta representando sua estimativa de forma privada, as cartas sao reveladas simultaneamente e os valores discrepantes explicam seu raciocinio. Repita ate convergir. O Planning Poker funciona bem porque a revelacao simultanea evita o vies de ancoragem. A discussao que se segue apos desacordos e onde voce realmente aprende. As equipes descobrem requisitos mal compreendidos e diferentes suposicoes sobre o escopo. E o metodo mais confiavel para estimativas detalhadas no nivel do sprint. Mas e lento. Estimar 30 itens do backlog um de cada vez pode consumir uma tarde inteira. E ai que as outras tecnicas entram.

Tamanhos de camiseta

Os tamanhos de camiseta substituem escalas numericas por rotulos familiares: XS, S, M, L, XL e as vezes XXL. Em vez de debater se algo e um 5 ou um 8, as equipes perguntam: "Isso e um medio ou um grande?"

Como executar

  1. Apresente os itens do backlog para a equipe
  2. Comece com um item de referencia com o qual todos concordam (por exemplo, "Este redesign da pagina de login e um Medio")
  3. Para cada item restante, a equipe discute e atribui um tamanho relativo a referencia
  4. Se houver desacordo, os valores discrepantes explicam seu raciocinio e se vota novamente

Quando usar

Os tamanhos de camiseta funcionam melhor no inicio de um projeto, quando voce precisa de estimativas aproximadas para o planejamento do roadmap. E mais rapido que o Planning Poker porque ha menos opcoes para deliberar, e os rotulos desencorajam falsa precisao. Ninguem discute sobre a diferenca entre XL e XXL da mesma forma que discute sobre 13 vs. 21 story points. Tambem funciona bem para stakeholders nao tecnicos. Gerentes de produto e designers entendem intuitivamente "isso e um Grande" sem precisar de uma introducao sobre sequencias de Fibonacci. Grupo de pessoas separando itens em baldes rotulados de pequeno a extra-grande, representando o dimensionamento relativo de tarefas usando categorias familiaresGrupo de pessoas separando itens em baldes rotulados de pequeno a extra-grande, representando o dimensionamento relativo de tarefas usando categorias familiares

Mapeamento por afinidade (estimativa por afinidade)

A estimativa por afinidade permite que equipes dimensionem um grande numero de itens rapidamente, comparando-os entre si em vez de compara-los a uma escala absoluta.

Como executar

  1. Escreva cada item do backlog em um cartao ou nota adesiva
  2. Coloque o primeiro item no meio de uma mesa ou parede
  3. Pegue o proximo item e pergunte: "Isso e maior, menor ou aproximadamente igual ao primeiro?"
  4. Coloque-o a esquerda se for menor, a direita se for maior, na mesma coluna se for semelhante
  5. Continue com cada item. Os membros da equipe podem silenciosamente reorganizar itens com os quais discordam
  6. Depois que todos os itens forem colocados, trace limites de coluna e atribua rotulos de tamanho a cada grupo
A fase de classificacao silenciosa e o segredo. Em vez de debater cada item em sequencia, varias pessoas movem cartoes simultaneamente. Desacordos surgem naturalmente quando alguem move um cartao e outra pessoa o move de volta. Esses itens especificos se tornam os pontos de discussao.

Quando usar

A estimativa por afinidade funciona melhor quando voce tem um backlog grande (30+ itens) e tempo limitado. As equipes podem classificar 50 itens em 20-30 minutos, algo que levaria horas com o Planning Poker. E particularmente util no inicio de um novo projeto ou apos uma grande sessao de refinamento de backlog.

Dot voting

O dot voting nao e estritamente uma tecnica de estimativa. E um metodo de priorizacao. Mas combina bem com a estimativa, ajudando as equipes a identificar rapidamente quais itens sao mais importantes.

Como executar

  1. Liste todos os itens em um quadro (fisico ou virtual)
  2. De a cada membro da equipe um numero fixo de pontos (normalmente 3-5)
  3. Cada pessoa coloca seus pontos nos itens que considera de maior prioridade
  4. Os itens com mais pontos sobem para o topo
Voce pode adicionar restricoes: "Voce so pode colocar um ponto por item" ou "Coloque seus pontos nos itens que voce acha que devemos estimar primeiro." Algumas equipes usam pontos de cores diferentes para dimensoes distintas (vermelho para risco, verde para valor).

Quando usar

O dot voting funciona melhor como uma etapa pre-estimativa. Em vez de estimar todo o seu backlog, vote por pontos primeiro para identificar os 10-15 itens principais e depois use Planning Poker ou tamanhos de camiseta apenas nesses. Isso economiza tempo e mantem a equipe focada no que realmente importa para o proximo sprint ou release. Maos colocando adesivos coloridos de pontos em um quadro cheio de cartoes de tarefas, alguns cartoes cobertos com varios pontos mostrando prioridades claras da equipeMaos colocando adesivos coloridos de pontos em um quadro cheio de cartoes de tarefas, alguns cartoes cobertos com varios pontos mostrando prioridades claras da equipe

Sistema de baldes

O sistema de baldes combina elementos do mapeamento por afinidade e do Planning Poker. E projetado para estimar grandes backlogs rapidamente com grupos maiores.

Como executar

  1. Crie "baldes" representando tamanhos de estimativa (0, 1, 2, 3, 5, 8, 13, 20, 40, 100)
  2. Escolha um item e coloque-o em um balde como referencia (a equipe deve concordar com este)
  3. Distribua os itens restantes igualmente entre os membros da equipe
  4. Cada pessoa coloca silenciosamente seus itens nos baldes relativos a referencia
  5. Depois que tudo estiver colocado, a equipe revisa em conjunto e discute itens que parecem estar mal posicionados
  6. Ajuste e finalize

Quando usar

O sistema de baldes funciona bem para backlogs grandes (50-200 itens) com equipes de 5-15 pessoas. Como a classificacao inicial e feita silenciosamente e em paralelo, e muito mais rapido que a estimativa sequencial. A fase de revisao mantem a honestidade sem exigir discussao sobre cada item.

Estimativa de tres pontos (PERT)

A estimativa de tres pontos vem do gerenciamento de projetos, nao do agile. Mas e util quando sua equipe precisa considerar a incerteza, especialmente em trabalhos desconhecidos.

Como executar

Para cada item, a equipe fornece tres estimativas:
EstimativaSignificado
Otimista (O)Tudo corre perfeitamente, sem surpresas
Mais provavel (M)Cenario realista com atrito normal
Pessimista (P)Tudo que pode dar errado da errado
A media ponderada e: (O + 4M + P) / 6 Por exemplo, se uma funcionalidade e estimada em 2 dias otimista, 5 dias mais provavel e 14 dias pessimista: (2 + 20 + 14) / 6 = 6 dias.

Quando usar

A estimativa de tres pontos vale o esforco quando a incerteza e alta: tecnologia desconhecida, integracoes com sistemas externos ou algo que a equipe nunca construiu. A estimativa pessimista forca as pessoas a pensarem sobre riscos que o Planning Poker frequentemente ignora. E excessiva para trabalhos rotineiros. Se sua equipe ja construiu dezenas de endpoints CRUD, voce nao precisa de tres estimativas para o proximo.

Escolhendo a tecnica certa

Nao existe um unico melhor metodo de estimativa. A escolha certa depende do contexto.
CenarioMelhor tecnica
Planejamento de sprint com 10-15 itensPlanning Poker
Planejamento de roadmap com dimensionamento aproximadoTamanhos de camiseta
Backlog grande (30+ itens), tempo limitadoMapeamento por afinidade
Priorizar o que estimar primeiroDot voting
Backlog enorme (50-200 itens), equipe grandeSistema de baldes
Trabalho com alta incertezaEstimativa de tres pontos
A maioria das equipes acaba combinando tecnicas. Dot voting para priorizar, mapeamento por afinidade para dimensionar o backlog de forma aproximada e depois Planning Poker nos itens do proximo sprint. Visao dividida mostrando diferentes tecnicas de estimativa sendo usadas lado a lado, com cartoes, pontos e rotulos de tamanho visiveis em diferentes grupos de pessoas colaborandoVisao dividida mostrando diferentes tecnicas de estimativa sendo usadas lado a lado, com cartoes, pontos e rotulos de tamanho visiveis em diferentes grupos de pessoas colaborando

Algumas coisas que se aplicam a todas

Nao importa qual tecnica voce use:
  • Estime relativamente entre si, nao em termos absolutos. "Isso e duas vezes mais complexo do que aquela pagina de login" e mais util do que "isso vai levar 3 dias."
  • Limite o tempo da sessao. A estimativa tem retornos decrescentes. Defina um cronometro e siga em frente quando estiver perto o suficiente.
  • Re-estime quando aprender algo novo. Estimativas sao instantaneos, nao compromissos. Atualize-as conforme os requisitos ficam mais claros.
  • Acompanhe a precisao ao longo do tempo. Apos alguns sprints, compare as estimativas com os resultados reais. Os padroes mostrarao onde sua equipe erra consistentemente.
Se voce quiser experimentar o Planning Poker com sua equipe, a ferramenta de Planning Poker da Kollabe suporta Fibonacci, tamanhos de camiseta e escalas personalizadas, e e gratuita para comecar.

Sim, e muitas equipes fazem isso. Uma abordagem comum: dot voting para priorizar e depois Planning Poker nos itens principais. Ou mapeamento por afinidade para todo o backlog e depois Planning Poker apenas nos itens onde a equipe discordou.

O Planning Poker se adapta mais naturalmente a ambientes remotos, ja que as ferramentas online gerenciam a revelacao simultanea. Tamanhos de camiseta e dot voting tambem funcionam bem com quadros virtuais. O mapeamento por afinidade e mais dificil remotamente porque perde parte de sua velocidade quando voce nao pode mover fisicamente os cartoes.

Story points (ou tamanhos abstratos) sao geralmente preferidos porque medem complexidade em vez de duracao. Estimativas de tempo sao influenciadas por quem esta fazendo o trabalho e tendem a se tornar compromissos. Os pontos permanecem relativos e flexiveis.

Acompanhe suas estimativas em comparacao com os resultados reais de cada sprint. Procure padroes: voce esta consistentemente subestimando integracoes? Superestimando trabalho de frontend? Os dados mostrarao onde calibrar. Alem disso, mantenha suas historias de referencia atualizadas. Seu "medio" de hoje pode ser diferente do seu "medio" de seis meses atras.
Última atualização em 09/02/2026