Anatomia de um Bom Ticket

A maioria dos tickets é ruim. São títulos vagos — "corrigir bug de login", "atualizar dashboard", "trabalho de backend" — sem descrição, sem critérios de aceitação e sem contexto para qualquer pessoa além daquela que os escreveu. Esses tickets criam a ilusão de rastreamento enquanto na verdade não rastreiam nada útil.

Um bom ticket tem três partes:

• Título como resultado. O título declara o que será verdadeiro quando o trabalho estiver concluído, não qual atividade acontecerá. "Usuários podem redefinir senha via email" é um resultado. "Trabalhar em coisas de senha" é atividade. A diferença importa porque títulos orientados a resultados são testáveis — você pode olhar para o trabalho finalizado e perguntar "isso é verdade?"
• Descrição como porquê. A descrição explica por que esse trabalho importa e fornece contexto suficiente para alguém não familiarizado entender a decisão. Não é um romance — duas a três frases que respondem "por que agora?" e "qual é o impacto para o usuário?"
• Critérios de aceitação como o quê. Uma lista curta de condições concretas e testáveis que definem "pronto". Não "deve funcionar bem" — mas "o endpoint retorna um 200 com um token válido, um 401 com credenciais expiradas e um 429 após 5 tentativas falhadas em 60 segundos."

O teste para um bom ticket é o teste de pegar: um desenvolvedor que não estava na reunião onde isso foi discutido poderia pegá-lo e entregá-lo sem fazer perguntas de esclarecimento? Se a resposta for não, o ticket não está pronto — é um marcador de posição.

Critérios de aceitação são a parte mais ignorada de um ticket e a mais cara de ignorar. Sem eles, "pronto" é o que quer que o desenvolvedor que trabalhou nisso ache que significa — o que pode não corresponder ao que o gerente de produto esperava, ao que o QA testará ou ao que o cliente realmente precisa.

Bons critérios de aceitação são concretos e testáveis. "A busca deve ser rápida" não é um critério de aceitação — é uma esperança. "Resultados de busca retornam em menos de 200ms para consultas de até 1.000 registros" é testável. "O formulário deve lidar com erros graciosamente" é vago. "O formulário exibe uma mensagem de erro inline vermelha quando o campo de email está vazio e o usuário clica em Enviar" é específico o suficiente para construir e verificar.

Critérios de aceitação devem ser acordados antes do trabalho começar, não escritos depois. Quando um desenvolvedor e um gerente de produto se alinham nos critérios antes da primeira linha de código, eles estão se alinhando no escopo. Sem esse alinhamento, o desenvolvedor constrói o que entendeu, o PM esperava algo diferente e o ticket volta — custando tempo para ambos e corroendo a confiança. Escrever critérios de aceitação antecipadamente leva 10 minutos. Refazer uma funcionalidade mal compreendida leva dias.

A descrição é a fonte da verdade. Comentários são a conversa sobre ela. Misturá-los é como os tickets se tornam ilegíveis.

A descrição deve conter tudo que alguém precisa para entender o trabalho: o contexto, os requisitos, os critérios de aceitação e quaisquer links relevantes. É escrita uma vez (e atualizada se o escopo mudar). É a parte que você lê primeiro quando pega um ticket, e deve responder suas perguntas sem exigir que você role por 47 comentários.

Comentários são para discussão que acontece durante o trabalho: perguntas de esclarecimento, negociações de escopo, atualizações de status, feedback de revisão. Comentários são somente-anexar e cronológicos — eles capturam a conversa, não a conclusão. Quando uma thread de comentários resolve uma pergunta que muda os requisitos, a resposta volta para a descrição. A descrição é editada; o comentário permanece como o registro de auditoria de como a decisão foi alcançada.

Equipes que despejam tudo em comentários acabam com tickets onde os requisitos reais estão enterrados no comentário #23, espremidos entre uma atualização de status e uma reação de emoji. O desenvolvedor que pega o ticket tem que ler toda a thread para reconstruir o estado atual. Isso não é coordenação — é arqueologia.