Estimativa de um bug relatado por um cliente
Como estimar um bug relatado por um cliente: o relato no ticket determina a dimensão. Como distinguir entre uma correção de uma linha e uma resposta que consome todo o sprint.
O problema não é o tamanho. O cliente é que é grande.
Um bug relatado por um cliente envolve um escopo que a equipe não consegue perceber apenas pelo ticket. A correção técnica pode ser uma única linha de código. Mas o trabalho em torno disso — reproduzir o problema nos dados do cliente, redigir um relatório pós-incidente, elaborar a resposta, decidir se deve-se creditar a conta, comunicar-se com outros clientes afetados — costuma ser a maior parte da história. Nada disso consta no ticket. Tudo isso reduz a velocidade.
Faça uma estimativa de duas coisas: a correção e a resposta. A correção é o Planning Poker normal. A resposta é algo pouco familiar para equipes de engenharia e costuma ser sistematicamente subestimada — e é por isso que os bugs relatados pelos clientes parecem se arrastar pelo sprint, mesmo quando a votação do baralho indicou um valor baixo.
O que se fala na sala
Backend: “A correção é de apenas uma linha.”
PM: “Qual conta fez a denúncia?”
Suporte: “O CSM deles está solicitando uma RCA até sexta-feira.”
Pergunta principal: “Outras contas foram afetadas? Precisamos enviar um e-mail para elas?”
QA: “Será que conseguimos reproduzir o problema usando os dados deles, ou precisamos de uma exportação com dados anônimos?”
Perguntas que vale a pena fazer antes de votar
- Quem registrou a ocorrência e qual é o ARR, o SLA ou o status do contrato dessa pessoa?
- É necessário realizar uma RCA ou uma análise pós-incidente externamente?
- Outras contas foram afetadas? E como podemos descobrir isso?
- Precisamos conceder crédito, reembolsar ou prorrogar o período de teste?
- Quem redige a resposta destinada ao cliente? E isso consta neste ticket?
- Reprodução: dados do cliente, dump com informações confidenciais removidas ou dados sintéticos?
Divisão ajuda: a correção é um ticket, a resposta é outro. Ambos passam pelo planning poker; apenas um deles é de natureza de engenharia.
Faça uma estimativa separada para a correção e para a resposta. O nome da conta é o que faz com que a resposta seja extensa.
Consulte erros comuns no Planning Poker sobre o risco de votar em tarefas que não são de responsabilidade da equipe. Dê uma olhada nos outros exemplos práticos de estimativa, ou inicie uma sessão gratuita de Planning Poker com as duas histórias já preparadas.