Como estimar bugs e tarefas de manutenção
Bugs não entram no backlog planejados. Quando aparecem, o time precisa decidir: consertamos agora ou depois? E quanto vai levar?
O problema de estimar bugs com story points
Story points medem complexidade relativa de novas features. Bugs não são features. Comparar complexidade de “construir checkout” com “debuggar error 500” é comparar laranjas com maçãs.
Abordagens para estimar bugs
1. T-Shirt Sizing para bugs
- XS — typo, label errada (5-30 min)
- S — bug simples, causa conhecida (1-2 horas)
- M — bug com investigação necessária (2-4 horas)
- L — bug complexo, possível refatoração (4-8 horas)
- XL — bug sistêmico, possível reescrita (1+ dia)
2. Lead time histórico
“Dos últimos 30 bugs, os ‘M’ levaram em média 3 horas. Esse parece M.”
3. Timeboxing de investigação
Se a causa é desconhecida:
“Vamos timebox 1 hora para investigar. Depois decidimos se estimamos o fix ou criamos um spike.”
4. Sem estimativa — só resolva
Para bugs críticos (produção, segurança):
“Não importa quanto leva, conserte agora.” Depois do fix, registre o lead time para referência futura.
Bug budget vs. interrupção de sprint
Bug Budget (recomendado)
Reserve 15-20% da capacidade do sprint para bugs. Dentro desse budget, o time prioriza.
“Temos 5 pontos de bug budget. Esse bug é 3 pontos. Cabe no sprint.”
Interrupção de Sprint
Se o bug é crítico e não cabe no budget:
- PO decide o que sai do sprint para entrar o bug
- “Para adicionar esse bug de 8 pontos, removemos a busca de 5 pontos e parte do relatório de 3 pontos.”
Tabela de referência de bugs
| Tipo | Tamanho típico | Quando estimar | Quando só resolver |
|---|---|---|---|
| Cosmético | XS | Sempre | — |
| Funcional simples | S | Sempre | — |
| Funcional complexo | M-L | Se não for urgente | Se for crítico |
| Sistêmico/segurança | XL | Nunca | Sempre agora |
| Performance | M-XL | Após diagnóstico | Se impacto alto |
Preventivo: bugs recorrentes
Se 40% dos bugs são do mesmo tipo (ex:NPE em produção), invista em prevenção:
“A cada sprint, 3 pontos são gastos com NPEs. Se adicionarmos optional chaining no padrão do time (5 pontos), economizamos ~15 pontos em 5 sprints.”
Métricas de bugs
Track por sprint:
- Count — quantos bugs foram reportados
- Bugs por módulo — onde estão os problemas?
- Lead time médio — quanto tempo para resolver?
- Bug rate — bugs por feature entregue
- Reabertura — quantos bugs voltaram após “fixed”?
Conclusão
Bugs não devem ser estimados com a mesma régua que features. Use T-Shirt sizing, lead time histórico ou simplesmente resolva e registre o tempo depois. O importante é ter budget de bugs para não inflacionar as features do sprint.