Como escrever critérios de aceitação no Jira — com exemplos práticos

“Os clientes podem alterar suas preferências de notificação” parece um item claro do Jira até alguém começar a desenvolvê-lo. A alteração é salva imediatamente? O que acontece se o salvamento falhar? A preferência ainda estará lá amanhã? Quais e-mails são afetados?

Os critérios de aceitação transformam essas perguntas em aberto em resultados combinados e observáveis. Eles ajudam as pessoas que solicitam, desenvolvem e revisam uma alteração a trabalhar com as mesmas expectativas.

Neste guia, desenvolveremos critérios para uma funcionalidade fictícia de portal do cliente, melhoraremos requisitos vagos e adicionaremos uma lista prática à ferramenta Definition of Done & AC do Power Pack. Você não precisa de um formato especial de escrita para começar. Condições e resultados claros bastam.

O que são critérios de aceitação?

Os critérios de aceitação descrevem as condições que um trabalho específico deve cumprir para ser aceito. Eles se concentram no resultado esperado daquele item. A Atlassian os diferencia da Definition of Done, que descreve o padrão mais amplo de qualidade do trabalho concluído. Consulte o guia de critérios de aceitação da Atlassian.

Em nosso exemplo, “Uma escolha de notificação salva permanece selecionada depois que o cliente entra novamente na conta” é um critério de aceitação. “A implementação foi revisada” pertence à Definition of Done compartilhada.

Essa distinção mantém as duas listas úteis. Os critérios de aceitação explicam se a funcionalidade faz o que a equipe combinou. A Definition of Done explica se o trabalho cumpre o padrão mais amplo de conclusão da equipe.

Nenhuma das listas precisa conter todos os passos de implementação. “Criar um campo no banco de dados” pode ser uma tarefa necessária de engenharia, mas não informa ao cliente ou a quem revisa se a preferência se comporta corretamente.

Comece com um resultado para o cliente

Nosso item fictício se chama “Permitir que os clientes controlem o e-mail de resumo semanal”. O resultado desejado é que um cliente autenticado possa escolher se recebe o resumo semanal sem alterar mensagens essenciais da conta.

Antes de escrever os critérios, a equipe combina algumas decisões de escopo. A configuração tem um botão explícito de Save. O cliente altera apenas a própria preferência. A preferência afeta resumos que ainda não entraram na fila. Mensagens já enfileiradas ficam fora da regra de envio deste item.

Esses detalhes foram inventados para o exemplo. Sua equipe deve decidir o comportamento real, em vez de copiá-los como requisitos de produto.

Uma pequena nota de escopo pode evitar que uma lista longa precise carregar todo o contexto. Na descrição do Jira, a equipe registra que o item abrange uma preferência na página de configurações da conta. Escolher dias de envio, alterar endereços de e-mail e gerenciar preferências de outros clientes são trabalhos separados.

Agora os critérios podem se concentrar nos resultados que demonstram se essa alteração específica funciona.

Escreva primeiro o caminho normal

Comece pela experiência que você espera que a maioria dos clientes siga. Descreva a condição inicial, a ação e o resultado observável em linguagem comum.

Por exemplo: “Quando um cliente autenticado desativa os resumos semanais e salva com sucesso, reabrir as configurações da conta mostra os resumos semanais desativados.” Quem revisa pode criar o estado inicial, executar a ação e inspecionar o resultado.

Essa frase é mais útil do que “As preferências são salvas corretamente”. Ela especifica qual preferência muda, quando a alteração passa a valer e como alguém pode verificá-la.

A equipe também precisa do sentido inverso. Um controle que desativa os resumos com sucesso, mas não consegue ativá-los, está incompleto. Escreva um critério separado quando o comportamento inverso merecer sua própria verificação.

Não force resultados sem relação a caberem em uma única entrada. Salvamento, operação por teclado, envio de e-mails e tratamento de erros podem ser importantes, mas um critério enorme dificulta mostrar qual parte ainda precisa de atenção.

Adicione cenários de falha e casos de limite

O caminho normal pressupõe que o salvamento funciona. Pergunte o que o cliente deve ver quando essa suposição for falsa.

Nossa equipe escolhe esta regra: se a solicitação de salvamento falhar, a página mostra um erro e não apresenta confirmação de sucesso. Ao reabrir a página, a preferência salva anteriormente permanece. Isso oferece a quem revisa um cenário concreto de falha para exercitar no ambiente de testes da equipe.

Depois, examine os limites da funcionalidade. A configuração de resumo semanal não deve impedir um e-mail de redefinição de senha. A escolha do cliente também deve sobreviver a uma nova sessão de login. São preocupações diferentes e, por isso, recebem critérios separados.

Evite escrever “Todos os casos de limite tratados”. Nomeie os casos importantes. Uma discussão útil costuma começar com três perguntas: o que pode falhar, o que deve permanecer inalterado e o que acontece depois?

Se a equipe não conseguir combinar um resultado esperado, registre a decisão pendente antes que a implementação avance demais. Uma pergunta sem resposta não se torna um critério utilizável apenas por estar em uma lista.

Uma lista completa de critérios de aceitação

Esta é a primeira versão completa do item fictício. Cada entrada descreve um resultado que a equipe pode verificar separadamente.

• Abrir as configurações da conta mostra a preferência de resumo semanal atualmente salva do cliente.
• Depois de desativar os resumos semanais e salvar com sucesso, reabrir as configurações mostra a preferência desativada.
• Depois de ativar os resumos semanais e salvar com sucesso, reabrir as configurações mostra a preferência ativada.
• Após um salvamento bem-sucedido, sair da conta e entrar novamente preserva a preferência salva.
• Se o salvamento falhar, um erro é mostrado, nenhuma confirmação de sucesso aparece e reabrir as configurações mostra a preferência salva anteriormente.
• Um cliente com a preferência desativada não recebe nenhum resumo semanal colocado na fila após o salvamento bem-sucedido.
• Um cliente com a preferência ativada continua elegível para o próximo resumo semanal segundo as regras existentes de agendamento.
• Desativar os resumos semanais não impede que o cliente receba um e-mail solicitado de redefinição de senha.

As entradas de envio dependem da decisão de escopo sobre mensagens enfileiradas. A equipe registra esse contexto junto ao item para que quem revisa não suponha que a configuração recupera e-mails que já estão sendo enviados.

Esses critérios também precisam de uma abordagem viável de verificação. Para o comportamento de envio, a equipe identifica como acionar ou observar um resumo no ambiente de testes. Um critério pode estar escrito com clareza e ainda ser difícil de verificar se ninguém tiver acesso à conta ou às evidências de envio necessárias.

Melhore os critérios vagos antes de adicioná-los

Uma revisão rápida da redação costuma evitar divergências mais longas depois. Leia cada entrada e pergunte se duas pessoas poderiam interpretar o sucesso de formas diferentes.

O último exemplo não comprova usabilidade por si só. Ele substitui uma frase vaga por uma verificação útil e limitada. Objetivos mais amplos de usabilidade podem exigir pesquisa ou várias observações combinadas.

Também tome cuidado com precisão inventada. Adicionar um requisito de resposta em dois segundos parece mensurável, mas cria um compromisso real. Combine as condições e a razão de um limite de desempenho antes de incluí-lo.

Coloque os critérios no Power Pack

Abra o item do Jira e encontre o cartão Definition of Done & AC. Selecione a aba Acceptance Criteria. Sua lista é separada da aba Definition of Done, então confira a aba selecionada antes de inserir o conteúdo.

Para adicionar um critério, digite seu título e selecione Add ou pressione Enter. Use títulos concisos que preservem o resultado esperado. Se um critério precisar de muito contexto, mantenha esse contexto na descrição do Jira ou na documentação vinculada da equipe.

Para várias entradas, selecione Bulk Import e cole uma lista com marcadores Markdown. Você pode copiar as entradas de exemplo acima, colocando um hífen e um espaço antes de cada uma. Listas de caixas de seleção Markdown também são aceitas.

Revise as entradas resultantes depois da importação. A ação acrescenta à lista atual, então importar a mesma lista novamente pode criar entradas já existentes. Caixas de seleção Markdown marcadas chegam como concluídas; comece com entradas desmarcadas, a menos que os resultados do item atual tenham sido realmente verificados.

Se uma entrada estiver errada, revise a nova redação com a equipe, adicione a entrada corrigida e exclua a obsoleta usando a confirmação exibida. Mantenha clara a discussão de apoio no item quando uma alteração afetar o escopo combinado.

Revise os resultados antes de marcá-los como concluídos

Antes da implementação, peça a alguém envolvido na verificação que percorra os critérios propostos. Essa pessoa pode identificar condições iniciais ausentes ou um resultado que não pode ser observado com a estrutura de testes disponível.

Após a implementação, verifique cada resultado e registre evidências pelo processo normal do Jira ou da documentação da equipe. Selecione o botão Done de uma entrada quando o resultado combinado tiver passado. Selecioná-lo novamente retorna a entrada a pendente se uma descoberta posterior reabrir a verificação.

Por exemplo, a preferência pode sobreviver a uma recarga de página, mas ser redefinida após um novo login. O critério de reabertura da página pode passar enquanto o critério de persistência entre sessões continua incompleto. Entradas separadas preservam essa distinção útil.

O Power Pack acompanha a conclusão da lista; ele não executa os testes nem estabelece automaticamente quem os revisou. Se a revisão exigir uma verificação nominal ou um resultado datado, registre esses detalhes explicitamente no processo normal.

Use as duas contagens sem confundi-las com comprovação

Acceptance Criteria e Definition of Done mostram, cada uma, suas próprias contagens de entradas concluídas e totais. O indicador exibe Ready for Release somente quando as duas listas não estão vazias e todas as entradas de ambas estão concluídas. Caso contrário, mostra In Verification.

Isso resume o estado das listas inseridas. Não demonstra que os critérios cobrem todos os comportamentos importantes nem que as evidências de apoio são sólidas. Também não impõe transições de fluxo de trabalho do Jira nem bloqueia integrações.

Nosso item de notificações pode ter todos os oito critérios de aceitação concluídos enquanto as orientações de suporte continuam inacabadas na Definition of Done. Os resultados da funcionalidade passaram, mas o acordo mais amplo de conclusão da equipe ainda tem uma entrada em aberto.

Comece com um próximo item do Jira. Escreva o resultado para o cliente, combine as condições e os resultados importantes e adicione os critérios ao Power Pack junto à Definition of Done compartilhada. Revise a lista com quem desenvolverá e verificará a alteração. O benefício é ter menos suposições escondidas atrás de uma frase que inicialmente parecia óbvia.

• Atlassian — O que são critérios de aceitação?