User Story Critério de Aceite: Guia com INVEST e Gherkin
Aprenda a escrever critério de aceite de user story com INVEST e Gherkin, exemplos bons e ruins lado a lado e erros que travam a sprint.
Uma user story sem critério de aceite claro chega na Revisão da Sprint sem jeito de o time dizer se ela está Pronta ou Não Pronta — e essa ambiguidade é justamente o que os critérios de aceitação existem para eliminar. Neste guia você vê, lado a lado, exemplo de critério de aceite bem escrito e mal escrito, como estruturar em Gherkin (Dado, Quando, Então) e onde a regra INVEST te avisa que a história vai travar antes mesmo de chegar ao QA.
Resumo em 30 segundos
- Critério de aceite é a condição objetiva que define quando uma user story está Pronta, servindo de regra de ouro para o Product Owner detalhar a história ao time.
- A estrutura Gherkin organiza o critério em três blocos — Given (Dado) para o contexto, When (Quando) para a ação e Then (Então) para o resultado esperado.
- O 'T' (Testable) do INVEST só se cumpre quando existe critério de aceite objetivo; histórias que agrupam muitas funcionalidades tendem a quebrar também o 'S' (Small).
- Critério de aceite é diferente de regra de negócio: a regra de negócio é uma condição permanente do domínio, enquanto o critério de aceite é específico daquela story e daquela sprint.
- Um erro recorrente é escrever Gherkin como transcrição de caso de teste tradicional, em vez de descrever comportamento em linguagem de negócio.
O que é critério de aceite de uma user story?
Critério de aceite de uma user story é a lista de condições que definem quando aquela história está pronta e funcionando como deveria — sem elas, "pronto" fica na cabeça de cada pessoa do time, e cada uma imagina um resultado diferente. Segundo a Scrum Academy, os critérios de aceitação dão clareza ao time acerca do que é esperado de uma user story, removem ambiguidades de requisitos e ajudam no alinhamento das expectativas entre quem pede a funcionalidade e quem vai construí-la (Scrum Academy). Na prática, é o critério de aceite que transforma uma frase vaga como "o usuário quer filtrar resultados" em algo que o time pode construir e testar sem margem para interpretação.
Esse papel não nasceu junto com o Scrum — vem de uma técnica mais antiga, conhecida como os 3 C's: Cartão, Conversa e Confirmação. O Cartão é o registro resumido da user story (o "quem, o quê, por quê"). A Conversa é o diálogo entre PO, time e stakeholders para destrinchar o que realmente precisa ser feito — e é exatamente nessa etapa que perguntas de levantamento de requisitos bem conduzidas fazem diferença, algo que um roteiro de entrevista de levantamento de requisitos ajuda a estruturar. Já a Confirmação é o critério de aceite propriamente dito: a lista de condições que, quando satisfeitas, confirmam que a conversa gerou o entendimento certo e que a story pode ser considerada concluída.
Essa ligação entre Confirmação e critério de aceite explica por que ele é chamado, em vários materiais de Scrum, de "regra de ouro" da user story: é o único elemento da técnica dos 3 C's que sobrevive à Sprint Review como evidência objetiva. Um exemplo prático: numa story do tipo "como cliente, quero filtrar receitas por tempo de preparo", a Conversa entre PO e time pode gerar critérios como "o filtro deve aceitar intervalos de 0 a 120 minutos" e "resultados sem tempo cadastrado não aparecem no filtro" — exatamente o tipo de condição objetiva que permite verificar se a funcionalidade atende ao requisito, como ilustra o exemplo do PMI aplicado a busca de receitas (flexible Methodology 4 Innovation). Sem essa etapa de Confirmação bem registrada, a story vira uma promessa sem verificação — e é aí que o critério de aceite se torna indispensável, não decorativo.
Critério de aceite, regra de negócio, cenário de teste e caso de teste: qual a diferença?
Esses quatro termos aparecem juntos em qualquer discussão sobre user story e por isso viram uma sopa de letrinhas na cabeça do gestor. Na prática, cada um vive numa camada diferente do mesmo problema: a regra de negócio é a lei que existe independente do sistema; o critério de aceite é a tradução dessa lei para uma story específica; o cenário de teste é a situação concreta usada para verificar aquele critério; e o caso de teste é o roteiro passo a passo, com dados e cliques, que alguém (ou uma automação) executa para confirmar que o cenário passou. Confundir essas camadas é o motivo mais comum de Gherkin inchado e retrabalho na Sprint Review.
Pegue a story "Como usuário, quero fazer login no sistema Portal RH para acessar meu contracheque". A regra de negócio, que vem antes de qualquer story e normalmente já está descrita num documento de requisitos, diz algo como: "a conta é bloqueada após 5 tentativas de senha incorreta, por política de segurança da empresa". Essa regra não muda story a story — ela é fixa, geralmente vem de compliance ou auditoria, e existiria mesmo que o Portal RH nunca tivesse sido construído em Scrum. O blog da Bruna Fonseca, um dos poucos a isolar esse conceito, é claro nesse ponto: regra de negócio e critério de aceite não são sinônimos, embora um alimente o outro.
O critério de aceite pega essa regra e a aplica à story do login: "o sistema deve bloquear a conta após a 5ª tentativa incorreta e exibir mensagem de erro". Já o cenário de teste é a situação escrita em Gherkin — Dado que o usuário errou a senha 4 vezes, Quando ele erra a 5ª vez, Então a conta é bloqueada — e o caso de teste é o roteiro operacional: usuário joana.rh@empresa.com, senha errada digitada cinco vezes seguidas, print da tela de bloqueio anexado como evidência.
O erro mais comum, apontado pela Revista DTAR, é o Gherkin virar caso de teste disfarçado — cheio de cliques e IDs de campo em vez de comportamento de negócio. Um critério de aceite bom fala a língua do PO; um caso de teste fala a língua do QA. Story sem essa distinção clara tende a nascer confusa desde a elicitação de requisitos.
Como escrever critério de aceite em Gherkin (Given, When, Then)
O Gherkin organiza cada critério de aceite em três blocos: Given (Dado), que descreve o contexto antes da ação; When (Quando), que descreve a ação do usuário; e Then (Então), que descreve o resultado esperado. Essa estrutura, usada por ferramentas como o Cucumber, existe para eliminar ambiguidade — o time lê a mesma frase e entende exatamente o que precisa ser construído e testado, sem depender de interpretação pessoal.
Veja isso aplicado a uma story real de e-commerce de receitas, adaptada do exemplo do PMI descrito pela flexible Methodology 4 Innovation: "Buscar receitas por ingrediente". O objetivo é permitir que o usuário digite um ingrediente e veja só as receitas compatíveis. Um critério de aceite completo ficaria assim:
Dado que estou na página de busca de receitas
Quando eu digito "frango" no campo de busca e confirmo
Então o sistema exibe apenas receitas que contêm frango como ingrediente
A diferença entre um critério útil e um inútil não está no formato Given/When/Then em si — está no nível de precisão de cada bloco. A tabela abaixo contrasta as duas versões da mesma regra de negócio:
| Critério ruim | Critério bom |
|---|---|
| Dado que o usuário está no sistema | Dado que estou logado e na página de busca de receitas |
| Quando ele busca algo | Quando eu digito "frango" e clico em buscar |
| Então mostra resultado | Então o sistema exibe somente receitas com frango, ordenadas por relevância |
O critério ruim não é falso, é inespecífico: qualquer comportamento do sistema o satisfaz, o que o torna impossível de reprovar em teste — na prática, quebra o
Como o INVEST evita critério de aceite fraco (e o que dá errado quando ignora)
O princípio INVEST — Independente, Negociável, Valiosa, Estimável, Small (pequena) e Testável — funciona como um filtro de qualidade que expõe critério de aceite fraco antes de a story entrar em sprint. O PM3 descreve o INVEST como ferramenta para escrever e, principalmente, quebrar user stories grandes em partes gerenciáveis. Na prática, dois critérios do acrônimo andam colados: quando o "S" falha — a story é grande demais, agrupando várias funcionalidades — o "T" falha junto, porque não dá para escrever um critério de aceite objetivo para algo que na verdade são cinco entregas disfarçadas de uma.
O Medium de Vanderlan Filho descreve exatamente esse anti-padrão: é muito comum observar estórias que agrupam muitas funcionalidades, resultando em confusão e dificuldade de desenvolver e testar. O efeito prático aparece no critério de aceite: em vez de três ou quatro cenários Gherkin claros, o time acaba com uma lista de dez ou mais condições que misturam cadastro, validação, notificação e relatório na mesma story. Ninguém consegue dizer com segurança quando ela está
Quantos critérios de aceite uma story precisa e quem deve escrevê-los?
Não existe número fixo — o que existe é um teste prático: uma user story precisa de critérios de aceite suficientes para que qualquer pessoa do time, sem perguntar nada ao PO, saiba dizer se a entrega está pronta ou não. Na prática isso costuma ficar entre 3 e 7 critérios por story. Menos que isso geralmente indica que a story está incompleta ou grande demais escondendo cenários (o "S" do INVEST quebrado); mais que isso é sinal de que ela deveria ser fatiada em stories menores. A Scrum Academy é direta nesse ponto: os critérios de aceitação removem ambiguidade e alinham expectativas — e é papel do Scrum Master proteger essa clareza, garantindo que o PO não altere os critérios no meio da sprint já em andamento. Mudar a régua depois que o time começou a correr invalida a Revisão da Sprint.
Quem escreve? A responsabilidade formal é do Product Owner, porque é ele quem detém a visão de negócio e responde pelo valor da entrega. Mas escrever sozinho, sem conversa, é o erro mais comum — e é exatamente o que a técnica dos 3 C's (Cartão, Conversa, Confirmação) tenta evitar: o critério de aceite é a Confirmação, e ela só nasce boa depois da Conversa entre PO, time de desenvolvimento e QA. O PMBOK reforça essa lógica formalizando o conceito de entregas aceitas: produtos e capacidades só são aprovados quando validados contra critérios previamente estabelecidos — conforme detalha o Escritório de Projetos na leitura da 8ª edição do guia. Ou seja, o critério não é um detalhe de redação: é o contrato que decide se a empresa paga a conta do que foi construído.
O equilíbrio de linguagem também importa na hora de escrever. A CWI resume bem a armadilha: priorize a linguagem do usuário e evite tecnicidades, mas não a ponto de faltar informação para o desenvolvimento. Um critério cheio de nomes de tabela e endpoint afasta o PO da conversa; um critério vago demais não dá ao time o que testar.
É aqui que a IA agrega valor real sem substituir ninguém: usada para gerar um primeiro rascunho de critérios a partir da story e revisar se cada um é testável, ela acelera a etapa mais mecânica do trabalho. Mas a conversa com o time — a validação de que aquele critério realmente reflete a regra de negócio — continua sendo humana. Esse mesmo raciocínio de acelerar sem eliminar a etapa de validação aparece em Como Usar IA para Levantar Requisitos de Software: Guia Prático, e se conecta diretamente ao ponto discutido em ROI de IA: por que só 5% das empresas colhem resultado real: ferramenta boa não compensa processo mal desenhado.
Perguntas frequentes
Qual a diferença entre critério de aceite e regra de negócio?
A regra de negócio é uma condição permanente do domínio, válida para todo o sistema (ex.: 'senha deve ter 8 caracteres'). O critério de aceite é específico de uma user story e de uma sprint, definindo quando aquela entrega pontual pode ser considerada Pronta.
User story sem critério de aceite pode entrar na sprint?
Tecnicamente pode, mas ela chega à Revisão da Sprint sem forma objetiva de o time dizer se está Pronta ou Não Pronta, já que os critérios de aceitação são o que remove a subjetividade da story. Na prática, isso gera retrabalho e discussão tardia sobre escopo.
Quem deve escrever os critérios de aceite: PO, QA ou o time todo?
A responsabilidade formal de garantir clareza é do Product Owner, com o Scrum Master zelando para que o critério não mude no meio da sprint. Mas a técnica dos 3 C's recomenda que a Confirmação nasça de uma conversa entre PO, dev e QA, não de um documento escrito isoladamente.
Escrever critério de aceite bom exige prática, mas o processo fica mais rápido quando a IA ajuda a transformar a conversa com o cliente em Gherkin estruturado e a revisar se cada critério é realmente testável antes de virar compromisso da sprint — é esse tipo de apoio que o espacoia.com.br oferece para quem já domina o processo de levantamento de requisitos, como no guia de elicitação de requisitos ou no modelo de documento de requisitos completo, e quer aplicar isso direto na escrita de user stories.