Algumas histórias escondem mais incerteza do que trabalho. Estimar o prazo de algo desconhecido é adivinhar; criar um spike é transformar a adivinhação em experimento com prazo, objetivo e critério de saída. A diferença entre as duas abordagens define a qualidade do planejamento.
O que é um spike e quando ele é necessário
Um spike é um item de trabalho temporário dedicado a responder uma pergunta: provar uma tecnologia, mapear uma integração, estimar uma massa de dados ou validar uma hipótese de arquitetura. Ele não entrega funcionalidade — entrega conhecimento.
Crie um spike quando a incerteza impede uma estimativa honesta: tecnologia nunca usada pelo time, integração com sistema externo pouco documentado, requisito que depende de decisão externa ou problema de performance cuja causa é desconhecida.
Como escrever um bom item de investigação
Um spike precisa de objetivo mensurável e tempo limitado. Em vez de "investigar autenticação", escreva "validar a biblioteca de autenticação X com os provedores Y e Z, prototipando o fluxo principal". O critério de saída é claro: saber o suficiente para decidir e estimar.
Defina também quem conduz e como o resultado será compartilhado. Um spike sem responsável e sem data de resposta vira pesquisa infinita; um spike sem compartilhamento devolve o time ao mesmo ponto de ignorância na próxima sessão.
Estimando spikes: faixa, não ponto
Spikes costumam ser estimados em faixas ou em tempo máximo, porque o trabalho é exploratório. Combine um timebox curto — uma ou duas sprints — e avalie o resultado ao final: continuar, mudar de abordagem ou encerrar com o que se aprendeu.
O risco de spikes é o perfeccionismo. Lembre o objetivo: o spike não precisa da solução final, apenas de informação suficiente para a decisão. Um protótipo descartável que respondeu a pergunta é um spike bem-sucedido, mesmo que vá para o lixo.
Convertendo aprendizado em histórias
O resultado de um spike deve virar histórico para o backlog: as descobertas viram histórias menores e bem definidas, e as decisões técnicas viram registros para quem for implementar. Sem essa conversão, o conhecimento morre com quem conduziu o experimento.
Na retrospectiva, avalie se os spikes realmente reduziram incerteza. Se as histórias derivadas continuam gerando votos dispersos, o spike foi superficial ou a pergunta errada foi respondida — e o formato merece revisão.
Checklist rápido
- Spike tem objetivo, timebox e critério de saída.
- Responsável definido e resultado compartilhado.
- Estimado em faixa ou tempo máximo.
- Aprendizado convertido em histórias e registros.
- Efetividade dos spikes avaliada em retrospectivas.
Leia também
- Refinamento ágil: como deixar histórias prontas para estimarAprenda a preparar backlog, critérios de aceite e perguntas de refinamento para chegar ao Planning Poker com histórias mais claras.
- Capacidade real da sprint: férias, suporte e imprevistos que ninguém calculaAprenda a calcular capacidade de forma realista considerando férias, suporte, cerimônias e imprevistos para planejar sprints honestas.
- 7 erros comuns no Planning Poker (e como evitar cada um)Ancoragem, histórias gigantes, votos contaminados e falta de registro: conheça os erros mais comuns do Planning Poker e como corrigi-los.
Quer colocar em prática?
Crie uma sala grátis de planning poker free, chame o time e faça a primeira rodada em menos de 2 minutos, sem cadastro nem instalação.