Postagens

Como escrever critérios de aceitação que realmente evitam retrabalho

Time ágil colaborando ao redor de uma mesa com post-its e um laptop, discutindo requisitos para uma história de usuário durante uma sessão de refinamento do backlog Problemas relacionados a requisitos causam quase metade de todos os defeitos em software. A maioria deles vem do mesmo problema raiz: o time construiu o que achava que foi pedido, não o que realmente era necessário. Os critérios de aceitação são a solução. Eles transformam uma história de usuário vaga em um contrato testável entre o product owner e o time de desenvolvimento. Quando bem escritos, eles eliminam as conversas de "mas eu pensei que deveria..." que descarrilam as revisões de sprint. Este guia cobre os dois formatos principais, exemplos reais que você pode adaptar e os erros que atrapalham até times experientes.

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

Critérios de aceitação são as condições que uma história de usuário deve satisfazer antes de ser considerada completa. Eles respondem uma pergunta: "Como saberemos que isso funciona?" Eles não são o mesmo que uma definição de pronto. A DoD é um padrão universal de qualidade que se aplica a todo trabalho (código revisado, testes escritos, deploy em staging). Critérios de aceitação são específicos para uma única história.

	Critérios de aceitação	Definição de Pronto
Escopo	Uma história de usuário	Todos os itens de trabalho
Foco	O que a funcionalidade faz para os usuários	Quão bem ela foi construída
Quem escreve	Product Owner + time	Todo o Time Scrum
Exemplo	"Usuário pode filtrar por intervalo de datas"	"Código revisado por pelo menos 1 dev"

Ambos devem ser satisfeitos antes que uma história esteja pronta. Se você ainda está construindo sua DoD, nosso Gerador de Definição de Pronto pode ajudá-lo a começar.

Os dois formatos principais

Formato checklist (baseado em regras)

Uma lista simples de condições passa/falha. Melhor para funcionalidades diretas onde o comportamento esperado é claro.

Funcionalidade de redefinição de senha:
- Link "Esqueci minha senha" aparece na página de login
- Clicar nele solicita um endereço de email
- Email válido recebe um link de redefinição em até 60 segundos
- Link de redefinição expira após 24 horas
- Nova senha deve atender aos requisitos de senha existentes
- Após redefinir, usuário é redirecionado ao login com mensagem de sucesso
- Email inválido mostra: "Se este email existir, um link de redefinição foi enviado"

Quando usar: Funcionalidades simples, requisitos de UI, regras de negócio, lógica de validação. A maioria das suas histórias usará este formato.

Formato Given/When/Then (Gherkin)

Um formato estruturado de cenário do Desenvolvimento Orientado a Comportamento. Cada cenário descreve uma pré-condição, uma ação e um resultado esperado.

Cenário: Aplicando um código de desconto válido
Given o usuário tem itens no carrinho totalizando R$ 100
And existe um código de desconto válido de 20% "ECONOMIZE20"
When o usuário insere "ECONOMIZE20" no campo de desconto
And clica em "Aplicar"
Then o total do carrinho atualiza para R$ 80
And uma mensagem "Desconto aplicado" aparece

Cenário: Aplicando um código de desconto expirado
Given o código de desconto "ANTIGO10" expirou ontem
When o usuário insere "ANTIGO10" e clica em "Aplicar"
Then o total do carrinho permanece inalterado
And uma mensagem de erro "Este código expirou" aparece

Quando usar: Fluxos complexos com múltiplos caminhos, ou funcionalidades que você planeja automatizar com ferramentas BDD como Cucumber ou SpecFlow. Dois documentos lado a lado mostrando o formato checklist e o formato Given/When/Then para critérios de aceitação, com anotações coloridas destacando as diferenças

Qual formato você deve escolher?

A maioria dos times adota uma abordagem híbrida: checklist para histórias simples, Given/When/Then para qualquer coisa com ramificações complexas ou múltiplos caminhos de usuário. Não complique demais. Escolha o formato que comunica os requisitos mais claramente para aquela história específica.

Cinco regras para escrever bons critérios de aceitação

1. Defina o o quê, não o como

Ruim: "Usar um componente modal com animação de fade-in de 400ms" Bom: "Diálogo de confirmação aparece antes do item ser excluído" Critérios descrevem resultados. Implementação é trabalho do desenvolvedor.

2. Torne cada critério testável

Se você não consegue responder "sim" ou "não" sobre se um critério foi atendido, ele está vago demais. Ruim: "A página deve carregar rapidamente" Bom: "Resultados de busca carregam em até 2 segundos para até 500 resultados"

3. Cubra o caminho infeliz

Para cada caminho feliz, escreva pelo menos um cenário de erro. O que acontece com entrada inválida? Uma conexão perdida? Permissões ausentes?

4. Mantenha critérios independentes

Cada critério deve ser verificável por conta própria. Se o critério #4 só faz sentido depois de ler os critérios #1 a #3, você escreveu uma especificação, não critérios de aceitação.

5. Escreva-os antes do planejamento da sprint

Critérios de aceitação escritos durante o desenvolvimento são descrições, não requisitos. Escreva-os durante o refinamento do backlog para que o time possa estimar com precisão durante o planning poker.

Exemplos do mundo real

Filtro de busca de e-commerce

História de usuário: "Como comprador, quero filtrar produtos por múltiplas categorias para poder reduzir os resultados ao que estou procurando."

• Filtros exibem todas as categorias de produtos disponíveis
• Usuários podem selecionar múltiplas categorias de uma vez
• Resultados atualizam em tempo real sem recarregar a página
• Filtros aplicados aparecem como badges removíveis
• Botão "Limpar tudo" remove todos os filtros ativos
• Contagem de resultados atualiza para refletir filtros ativos (ex: "Mostrando 47 resultados")
• Nenhum resultado correspondente mostra: "Nenhum produto corresponde aos seus filtros. Tente ampliar sua seleção."
• Estado do filtro persiste ao navegar de volta da página de detalhes do produto

Fluxo de convite para o time

História de usuário: "Como líder de time, quero convidar membros por email para que possamos começar a colaborar."

Cenário: Convite bem-sucedido
Given estou na página de configurações do time
When insiro "alex@empresa.com" no campo de convite
And clico em "Enviar Convite"
Then um email de convite é enviado em até 60 segundos
And o email aparece na minha lista "Convites Pendentes"
And uma mensagem de sucesso confirma que o convite foi enviado

Cenário: Convite duplicado
Given já convidei "alex@empresa.com"
When insiro o mesmo email e clico em "Enviar Convite"
Then um aviso aparece: "Convite já enviado para este email"
And posso escolher reenviar ou cancelar

Cenário: Formato de email inválido
Given estou na página de configurações do time
When insiro "nao-eh-email" e clico em "Enviar Convite"
Then um erro inline aparece: "Digite um endereço de email válido"
And nenhum convite é enviado

Preferências de notificação

História de usuário: "Como usuário, quero controlar quais notificações recebo para não ser sobrecarregado por alertas."

• Página de configurações mostra toggle para cada categoria de notificação
• Mudanças salvam automaticamente (sem botão "Salvar" separado)
• Desativar uma categoria interrompe todas as notificações daquele tipo em até 5 minutos
• Pelo menos um canal de notificação deve permanecer ativo (prevenir desativação acidental de tudo)
• "Restaurar padrões" restaura as configurações originais de notificação
• Mudanças se aplicam em todos os dispositivos

Um desenvolvedor revisando um card de história de usuário com critérios de aceitação claramente escritos, marcando itens um por um

Erros comuns

Ser vago demais. "O sistema deve ser amigável ao usuário" não é testável. Substitua linguagem subjetiva por condições mensuráveis. Prescrever implementação. "Usar Redux para gerenciamento de estado" pertence a uma spike técnica, não em critérios de aceitação. Descreva o que o usuário experimenta, não como o código funciona. Escrever apenas o caminho feliz. Se seus critérios cobrem apenas o cenário ensolarado, seu time descobrirá casos extremos no meio da sprint e ou cortará caminhos ou estourará a estimativa. Escrever critérios tarde demais. Critérios escritos durante o desenvolvimento são justificativas retroativas, não requisitos. Defina-os durante o refinamento, refine-os durante o planejamento da sprint. Tornar critérios granulares demais. Se seus critérios leem como um script de teste com 30 passos, você foi longe demais. Mire em 5-10 critérios por história. Se precisar de mais, a história provavelmente é grande demais e deve ser dividida em histórias menores.

Uma verificação rápida

Antes de comprometer uma história para uma sprint, passe por isto: Se algum desses falhar, a história precisa de outra rodada de refinamento do backlog antes de estar pronta para a sprint.

Escrevendo critérios de aceitação mais rápido

A abordagem "Três Amigos" funciona: coloque o product owner, um desenvolvedor e um testador na mesma sala para cada história. O PO explica a intenção, o desenvolvedor identifica casos extremos técnicos, e o testador faz furos com perguntas "e se...?". Se você está escrevendo histórias de usuário e precisa de um ponto de partida, nosso Gerador de Critérios de Aceitação pode rascunhar critérios iniciais a partir da descrição de uma história. Ele te dá os primeiros 80% rapidamente para que seu time possa gastar o tempo de refinamento nos casos extremos complicados ao invés de encarar uma página em branco.