Planning poker para devs: como estimar bugs, spikes e tarefas técnicas

O que muda quando o item não é uma história de usuário

História de usuário tem valor de negócio e critério de aceite. Bug, spike e tarefa técnica não têm esse formato, mas consomem capacidade do mesmo jeito. A pergunta que decide se o item entra na votação é prática: ele vai disputar espaço na sprint e precisa ser comparado com o resto?

Três casos resumem o problema: bug que consome dias, spike que ninguém sabe dimensionar e refatoração que precisa caber no planejamento. Para os três, a resposta costuma ser uma política combinada pelo time, e o papel deste guia é mostrar as opções, sem receita fixa.

Bugs: estimar, dar tamanho padrão ou só priorizar?

Existem três políticas comuns, e todas funcionam quando o time mantém consistência. O que não funciona é decidir caso a caso, toda sprint, sem combinado.

• Estimar como qualquer item. O bug entra na mesa, recebe um número por comparação e disputa a sprint com o resto. Funciona bem quando o bug é grande ou incerto e a decisão do que cabe precisa ser explícita.
• Tamanho padrão. Alguns times combinam que todo bug recebe o mesmo valor, para não gastar sessão discutindo detalhe. O risco é o valor fixo esconder bugs grandes, que deveriam ter tratamento próprio.
• Só priorizar. Bug urgente entra por prioridade, fora da estimativa, com o custo tratado como parte do trabalho do time. Se isso vira regra para tudo, nenhum bug tem tamanho visível e a previsão perde precisão.

Bug achado dentro da sprint é diferente de bug no backlog do produto. O primeiro geralmente faz parte do item em andamento: corrigir é concluir o que já foi combinado, e o time só estima de novo se o escopo mudou. O segundo não tem dono nem sprint, e é aí que a política entra: ele vira item estimado, item de tamanho fixo ou trabalho priorizado.

Como escolher? Experimente uma política por algumas sprints e compare a estimativa com o que os bugs consumiram de verdade. Quando os votos de um bug abrirem discussão de escopo, o guia de votos divergentes tem o roteiro da conversa.

Spikes: investigação com timebox

Spike é uma investigação: o time não sabe o suficiente para estimar e precisa descobrir. O combinado que costuma funcionar tem três peças: um objetivo escrito, um limite de tempo e um ponto de revisão onde o resultado volta para o time.

• Objetivo. Uma pergunta específica, do tipo "dá para usar o provedor novo de pagamento?".
• Limite de tempo. O timebox é a peça central. Duas horas, um dia ou o que o time decidir; sem ele, investigação vira projeto paralelo.
• Ponto de revisão. O que será apresentado no fim, mesmo que a resposta seja "não dá".

Quando a spike estoura, o time decide no ponto de revisão: encerrar com o que aprendeu, dividir a pergunta em outra spike menor ou aceitar mais incerteza e estimar o item com o que já sabe. O que não funciona é estender o prazo em silêncio.

Sobre estimar a spike em si: como o resultado é desconhecido, faz mais sentido limitar por tempo do que atribuir pontos ao que ela vai encontrar. Se o time quiser registrar algo, registre o investimento, como meia sprint de investigação, e mantenha a convenção estável.

Refatoração, dívida técnica e tarefas técnicas

Tarefa técnica sem referência não tem âncora. A saída é escolher um item entregue parecido e comparar: uma migração de biblioteca parecida com a última, um ajuste de consultas parecido com o trabalho do mês passado. Se a comparação não existe, divida a tarefa até cada parte ter referência possível.

Dívida técnica costuma ser maior do que parece para quem não está no código. Antes de votar, o time precisa explicar o problema e o resultado esperado, como faria com qualquer história. Sem isso, o voto mede o entendimento de cada um, não o trabalho.

Quando a refatoração é grande demais para uma sessão, corte por área, e cada parte vira um item com referência própria. É o mesmo movimento do item que chega ao teto da escala, descrito no guia de Fibonacci.

Como votar com o baralho do Pointly

O deck do Pointly é o mesmo para qualquer tipo de item: 0, ½, 1, 2, 3, 5, 8, 13 e a carta de pausa. A leitura também é a de sempre: itens pequenos e conhecidos nas cartas baixas, itens grandes e incertos nas altas.

Em item técnico, a pausa (☕) ganha um uso específico: sinalizar que falta informação para votar, como um detalhe de infraestrutura que ninguém pesquisou. Ela conta presença, mas fica fora da média, da mediana e do intervalo, então não distorce as contas do reveal.

Se o item chega a 13, o sinal é dividir antes de começar. O deck termina em 13 de propósito: acima disso a estimativa vira chute e a conversa rende mais separando o trabalho.

O comportamento completo do reveal e o roteiro de divergência estão no guia de como jogar.

Checklist: este item está pronto para votar?

• O problema está descrito. Sintoma, contexto e o que conta como resolvido, mesmo que em uma frase.
• O time sabe o que não sabe. Dúvida de infraestrutura, dependência externa ou dado desconhecido anotados antes do voto.
• Há uma referência. Um item entregue parecido, ainda que a comparação seja grosseira.
• O item cabe na sprint? Se não cabe, divida antes de votar, em vez de espremer no tempo.
• A política está combinada. Bug entra por estimativa, tamanho fixo ou prioridade? Spike conta na velocidade? O time já respondeu isso.
• O resultado tem destino. O número combinado vai para o backlog na hora, porque a sala do Pointly é efêmera e não guarda histórico.

Erros comuns de times de engenharia

• Estimar dívida técnica sem explicar. Vira votação no escuro: quem escreveu o código leva vantagem e o número fica pessoal.
• Spike sem timebox. Investigação aberta vira projeto e passa a competir com o compromisso da sprint.
• Usar tamanho fixo para tudo. Bug gigante com meio ponto esconde esforço e quebra a previsão das próximas sprints.
• Deixar bug urgente fora de qualquer registro. Quando a conta da sprint fecha, ninguém sabe quanto do tempo foi para bug.
• Tratar refatoração como invisível. Se o trabalho não aparece no plano, ele não é planejado, e a sprint estoura.
• Reestimar por pressão. Mudar o número para o item caber inverte a lógica: o backlog é que se ajusta.

Perguntas frequentes