Critérios de aceitação: como redigi-los

Os critérios de aceitação são o teste de aprovação ou reprovação de uma história, redigidos antes do início do trabalho — os formatos que funcionam, exemplos práticos e como eles diferem da definição de “concluído”.

Os critérios de aceitação são as condições que uma história deve cumprir para ser aceita — um teste do tipo “aprovado/reprovado”, definido antes de alguém começar a programar. Não há pontuação parcial: ou todas as condições são atendidas ou não são. Eles descrevem o que o resultado deve fazer, não como construí-lo. E são um teste, não uma segunda descrição do recurso. Se você conseguir atendê-los com um código que não resolve o problema, eles não são critérios de aceitação — são requisitos disfarçados.

Toda história traz uma pergunta implícita: como saberemos que ela está concluída? Os critérios de aceitação respondem a essa pergunta abertamente, antes mesmo do início do trabalho. Defina-os corretamente e a estimativa fica mais fácil, a demonstração se faz sozinha e o conceito de “concluído” deixa de ser uma negociação. Defina-os de forma vaga e você acabará lançando um recurso sobre o qual ninguém chegou a um acordo.

O que são critérios de aceitação e o que eles não são

Um bom critério de aceitação é algo que você poderia entregar a um testador que nunca tenha participado de sua reunião de refinamento, e ele saberia exatamente o que verificar. Ele descreve um resultado que o usuário pode observar, não a implementação que o produz. “Usar um cache Redis” não é um critério de aceitação — é uma solução. “Os resultados são carregados em menos de um segundo para uma tabela de 10.000 linhas” é um critério de aceitação, porque qualquer pessoa pode testá-lo e ninguém precisa ler o código para fazer isso.

Além disso, não se trata de uma lista de desejos. Cada critério precisa ser falsificável. Se uma afirmação não puder ser verificada — “a página é intuitiva”, “o desempenho é bom” —, não é um critério, é uma esperança. Elimine-a ou torne-a mensurável.

Os dois formatos que funcionam

Use Given/When/Then para comportamentos que dependem do estado e uma simples lista de verificação para um conjunto de requisitos independentes. A maioria das equipes recorre ao Given/When/Then para tudo; evite isso. Uma lista de verificação é mais rápida de ler e mais difícil de inflar quando a história se resume a “essas cinco coisas devem ser verdadeiras”.

Dado que / Quando / Então

Dado um estado inicial, quando o usuário realiza uma ação, o sistema responde de uma maneira específica. Esse formato se justifica ao obrigar que você identifique todos os três elementos — a pré-condição, o gatilho e o resultado observável —, que é exatamente o que um critério vago deixa de fora.

Exemplos de critérios de aceitação

Uma história de login, escrita no formato Dado/Quando/Então:

  • Dado um usuário cadastrado na página de login, quando ele digita um e-mail e uma senha corretos, então ele é direcionado para o seu painel de controle.
  • Se um usuário cadastrado digitar uma senha errada três vezes, então a conta fica bloqueada por 15 minutos e ele vê quanto tempo ainda resta.
  • Considerando a página de login, quando o campo de e-mail estiver vazio, então o botão de envio fica desativado.

Uma história sobre “filtrar a tabela de resultados”, escrita na forma de uma lista de verificação:

  • O filtro é aplicado ao selecionar — não há um botão separado para “aplicar”.
  • Dois filtros são combinados com “E”, e não com “OU”.
  • Ao limpar todos os filtros, a lista completa e sem ordenação é restaurada.
  • Um conjunto de resultados vazio indica o estado “sem correspondências”, e não uma tabela em branco.

Observe o que ambos omitem: o banco de dados, a estrutura e os nomes dos componentes. Eles descrevem o que o usuário recebe, não como você vai entregar isso — e cada linha é um elemento que um testador pode aprovar ou reprovar sem precisar fazer nenhuma pergunta a você.

Como redigir critérios de aceitação

  • Escreva-as durante o aperfeiçoamento do backlog, junto com a equipe — não sozinho, depois.
  • Um resultado observável por linha. Se uma linha contiver um “e” que realmente tenha efeito, isso significa dois critérios.
  • Identifique o caminho indesejado. O estado vazio, o tempo limite, a entrada incorreta — é aí que se esconde o esforço.
  • Concentre-se no comportamento, não no design. O protótipo aborda o layout; os critérios abordam o que precisa ser verdadeiro.
  • Pare por volta das cinco.

Quantos critérios de aceitação já são demais?

Mais ou menos cinco. Não porque exista uma regra, mas porque uma história que precisa de dez condições distintas e testáveis contém dez partes distintas de valor — o que significa que são várias histórias fingindo ser uma só. Quando a lista fica longa, os critérios de aceitação são a divisão.

Divisão por critérios de aceitação

Se uma história tiver mais de cinco critérios de aceitação, esses critérios costumam ser o que divide a história. A lista é um backlog que funciona como uma lista de verificação.

Os critérios de aceitação existem para descrever uma história. Eles não devem ser a história em si. Quando a lista fica longa — seis, oito, dez itens —, muitas vezes a equipe já fez a divisão sem perceber. Cada critério é uma pequena parte que a equipe poderia entregar, demonstrar e encerrar. Tratar a lista inteira como um único compromisso força a equipe a assumir tudo de uma vez, o que é a pior combinação de tamanho e risco que se pode atribuir a alguém em um sprint.

Para separar, analise cada critério e faça a pergunta que você faria sobre qualquer história de usuário: a equipe lançaria isso por conta própria? O usuário se beneficiaria disso por si só? Seria possível fazer uma demonstração? Os itens que passarem nesse teste são histórias. Os itens que não passam nesse teste geralmente pertencem a uma das histórias que sobreviveram — eles são parte do escopo de uma história que você já separou, e não um trabalho independente.

Onde isso falha é em critérios fortemente interligados — “o formulário valida os dados inseridos e salva no banco de dados e exibe uma confirmação”. Esses três itens parecem poder ser separados, mas o usuário não ganha nada se apenas um for entregue. Isso não é separável por critério; é uma única pequena história, e os itens listados são apenas uma demonstração de que a equipe está sendo meticulosa.

Critérios de aceitação x requisitos

Um requisito define o que deve ser desenvolvido. Um critério de aceitação define como você saberá se desenvolveu o que era esperado. “Os usuários podem redefinir suas senhas” é um requisito — e você pode atendê-lo com um fluxo tão falho que ninguém consegue concluí-lo. “Um usuário que solicita a redefinição recebe um e-mail em até dois minutos, cujo link expira após uma hora” é um critério de aceitação, pois é um teste no qual o fluxo falho é reprovado. Os requisitos definem o escopo do trabalho; os critérios determinam sua aceitação.

Critérios de aceitação versus a definição de “concluído”

Esses conceitos são constantemente confundidos, mas a distinção é simples: os critérios de aceitação são por história; a definição de concluído é global. Os critérios acima descrevem o que a história de login deve fazer especificamente. A definição de “concluído” — testado, revisado, documentado e implantado no ambiente de teste — se aplica a todas as histórias que a equipe entrega. Uma história pode atender aos seus critérios de aceitação e ainda assim não estar concluída, pois “funciona conforme especificado” e “pronto para lançamento” são padrões diferentes. É preciso atender a ambos.

Pontos de história x critérios de aceitação

Os critérios de aceitação descrevem o resultado — o que precisa estar cumprido para que a história seja considerada entregue. Pontos de história descrevem o caminho — qual é a magnitude do trabalho entre “ainda não temos isso” e “os critérios foram atendidos”. São dois eixos diferentes. Confundir os dois resulta em critérios quantificados, o que não faz sentido, ou em estimativas de pontos sem critérios por trás, o que é uma mera ilusão.

A adição de um critério altera a estimativa? Às vezes. Um critério que revela trabalho oculto — “deve ser acessível a leitores de tela” — geralmente altera, pois identifica um esforço que antes era implícito. Um critério que apenas esclarece uma suposição já existente — “deve funcionar no Chrome e no Safari”, quando esses sempre foram os navegadores compatíveis — não deveria alterar. A ordem é importante: primeiro os critérios, depois os pontos. Fazer uma estimativa antes que os critérios estejam claros é estimar antes do refinamento, e essa é a causa mais comum de votos muito dispersos.

Escreva o teste antes de começar a trabalhar. Se um critério não pode falhar, ele não é um critério — e se você tiver mais de cinco, provavelmente tem mais de uma história.

Perguntas frequentes

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

Os critérios de aceitação são as condições que uma história deve satisfazer para ser aceita — um teste do tipo “aprovado/reprovado” elaborado antes do início do trabalho. Eles descrevem o que o resultado deve fazer, não como construí-lo, e não há pontuação parcial: cada critério é atendido ou não é.

Como se redigem critérios de aceitação?

Escreva cada uma delas como se fosse algo que você pudesse entregar a um testador que nunca tenha visto a história. Use “Dado que/Quando/Então” para comportamentos que dependem do estado, ou uma simples lista de verificação para um conjunto de requisitos independentes. Faça com que sejam testáveis, concentre-se nos resultados e limite-se a cerca de cinco — se forem mais do que isso, você estará lidando com várias histórias.

Qual é a diferença entre critérios de aceitação e requisitos?

Os requisitos definem o que deve ser desenvolvido; os critérios de aceitação definem como saberá se está correto. Um requisito pode ser atendido por um código que não atinge o objetivo. Um critério de aceitação é um teste — se for aprovado, essa parte da história está concluída; se for possível ser aprovado sem resolver o problema do usuário, trata-se de um requisito disfarçado.

Qual é a diferença entre critérios de aceitação e a definição de “concluído”?

Os critérios de aceitação são específicos para cada história — eles descrevem o que essa história em particular deve fazer. A definição de “concluído” é uma lista de verificação global que se aplica a todas as histórias (testada, revisada, documentada, implantada). Uma história pode atender aos seus critérios de aceitação e ainda assim não estar concluída se não passar pela etapa de aprovação de toda a equipe.

Quem redige os critérios de aceitação?

O proprietário do produto é responsável por eles, mas são elaborados em conjunto com a equipe durante o refinamento. O proprietário do produto define o resultado esperado; os engenheiros e testadores identificam os casos extremos. Os critérios de aceitação elaborados isoladamente, após o fato, são aqueles que deixam de detectar o caso que causa falhas na produção.

Leituras relacionadas