Spike técnico: quando investigar antes de estimar

Nem sempre o time tem informação suficiente para estimar. Quando a incerteza é técnica, a resposta não é chutar — é investigar. É para isso que serve o spike técnico.

O que é um spike

Um spike é uma tarefa de investigação com timebox. O objetivo não é entregar código de produção, mas adquirir conhecimento suficiente para estimar e planejar o trabalho real.

“Spike de 2 dias para investigar se a API do parceiro suporta webhooks.”

Quando usar um spike

Tecnologia nova

“Nunca usamos GraphQL. Spike de 2 dias para avaliar se vale a pena migrar.”

Integração desconhecida

“Não sabemos se o gateway de pagamento aceita nossa arquitetura. Spike de 1 dia para testar sandbox.”

Risco técnico alto

“Precisamos processar 1M de registros em < 5s. Spike para testar se Redis é suficiente ou se precisamos de outra abordagem.”

Múltiplas soluções possíveis

“Podemos usar ElasticSearch, Algolia ou Search do Postgres. Spike de 3 dias para comparar as três.”

Como definir um spike

Timebox fixo

Um spike sempre tem duration máxima definida. 1-3 dias é o mais comum. Se o tempo acabar e a resposta não estiver completa, o spike gera o que tem e o time decide se faz outro spike ou estima com a incerteza.

Objetivo claro

“Descobrir se a API X suporta Y e qual é o custo por requisição.”

Não é “estudar a API X” — é algo específico e verificável.

Output definido

O output de um spike é conhecimento, não código:

• Documento com descobertas
• Prova de conceito (código descartável)
• Recomendação prosseguir ou não
• Estimativa refinada para a tarefa principal

Estimando um spike

Spikes são estimados em tempo, não pontos:

“Esse spike leva 2 dias” porque é um esforço de investigação com prazo definido.

O resultado do spike então permite estimar a tarefa real em pontos de história.

Fluxo completo

1. Identificação: “Não temos informação suficiente para estimar essa tarefa”
2. Criação do spike: Define objetivo, timebox e output esperado
3. Execução: Membro(s) investigam dentro do timebox
4. Resultado: Documento/encontro de sharing com descobertas
5. Re-estimativa: Time faz Planning Poker com informação nova

Exemplo prático

Cenário

PO quer “notificações push no mobile”. O time nunca implementou isso.

Sem spike

Time chuta: “8 pontos.” Implementação revela: Firebase, certificados APNs, fallback para iOS, rate limit… Vira 21 pontos. Sprint atrasado.

Com spike

• Spike: 2 dias, objetivo “avaliar as opções de push para iOS e Android e estimar esforço”
• Descoberta: Firebase Cloud Messaging (gratuito), APNs para iOS (complexidade de certificados), necessidade de backend para gerenciar tokens
• Estimativa pós-spike: 13 pontos com confiança alta
• Resultado: planejamento correto, sprint no prazo

Anti-padrões de spike

Spike sem timebox

“Spike para estudar Kubernetes” sem prazo vira procrastinação produtiva.

Spike que vira produção

Código de spike é descartável. Se virar produção, você entrega algo feito com pressa de investigação.

Spike demais

Se mais de 20% das tarefas precisam de spike, o time não tem conhecimento suficiente do domínio ou da base de código.

Conclusão

Spikes técnicos são a forma ágil de dizer “não sabemos o suficiente” sem parecer incompetente. São investimento em informação — e informação boa produz estimativas boas, que produzem planejamentos bons. Um spike de 2 dias evita um sprint de 10 dias na direção errada.