Critérios de aceite: como escrever (com exemplos)

O que são critérios de aceite

Critérios de aceite (em inglês, acceptance criteria) são a lista de condições que uma user story precisa cumprir para ser considerada pronta aos olhos de quem pediu o trabalho. Eles descrevem o resultado esperado — o que precisa acontecer, o que precisa aparecer, o que não pode quebrar — em linguagem simples, e são combinados antes de o trabalho começar. A regra é binária: se todos os critérios passam, o item está aceito; se um único critério falha, o item ainda não está pronto, por mais esforço que tenha sido investido.

Pense neles como o contrato miúdo de cada entrega. A user story bem escrita diz quem precisa de quê e por quê; os critérios de aceite dizem como todo mundo vai reconhecer que aquilo foi entregue. "Criar a página de inscrição do evento" é uma intenção. "A página carrega no celular, o formulário exige nome e e-mail, e quem se inscreve recebe confirmação por e-mail em até 5 minutos" é um combinado verificável — qualquer pessoa do time consegue olhar e responder sim ou não.

E isso não é coisa só de time de tecnologia. Um time de marketing pode definir critérios para uma campanha, o RH para um processo de onboarding, o financeiro para um novo fluxo de reembolso. Onde houver alguém pedindo trabalho e alguém entregando, existe espaço para a pergunta que os critérios de aceite respondem: "como saberemos que ficou pronto do jeito certo?"

Por que eles evitam retrabalho (e a discussão no fim da sprint)

Todo gestor já viveu esta cena: o time apresenta o trabalho na sprint review, o solicitante franze a testa e solta o clássico "não era bem isso que eu pedi". Ninguém agiu de má-fé — cada um só preencheu as lacunas do pedido com a própria imaginação. O problema é que essa descoberta acontece no momento mais caro possível: depois de dias de trabalho, no fim da sprint, na frente de todo mundo.

Critérios de aceite mudam o momento em que a ambiguidade morre. Em vez de descobrir a divergência na entrega, o time descobre na conversa de refinamento ou de planning, quando corrigir custa cinco minutos de discussão em vez de uma semana de retrabalho. Quando alguém pergunta "e se a pessoa se inscrever duas vezes com o mesmo e-mail?", o combinado fica registrado antes de qualquer trabalho começar.

Eles também despersonalizam a aceitação. Sem critérios, aprovar uma entrega vira julgamento de gosto — e recusar vira conflito pessoal. Com critérios, a conversa é sobre uma lista que os dois lados escreveram juntos: "o critério 3 diz que o e-mail de confirmação chega em até 5 minutos; nos meus testes levou meia hora, então falta esse". Firme, objetivo e sem drama. Para quem executa, é proteção contra o escopo que cresce sem parar; para quem pede, é garantia de que o essencial não será esquecido.

Há um bônus silencioso: critérios claros melhoram a estimativa em story points. É muito mais fácil dimensionar "formulário com 3 campos obrigatórios e e-mail de confirmação" do que "página de inscrição" — boa parte das estimativas erradas nasce de história mal delimitada, não de conta mal feita.

Quem escreve — e quando

A primeira versão dos critérios é responsabilidade de quem pediu o trabalho: o dono do produto, o gestor da área, o solicitante da demanda. Faz sentido — é essa pessoa que sabe o que precisa acontecer para o pedido valer a pena. Mas a versão final nunca deve ser um monólogo. Quem vai executar lê, questiona e completa: "e se o pagamento falhar?", "isso vale também para quem acessa pelo celular?", "o que acontece com quem já está cadastrado?". Cada pergunta dessas é um retrabalho que deixou de existir.

O momento certo é antes de a sprint começar — no refinamento do backlog ou, no limite, na planning, quando o time vai montar a sprint. História que entra na sprint sem critérios de aceite é um cheque em branco: o time se compromete com algo que ainda não foi definido. E escrever critérios depois que o trabalho começou tem um vício sutil — a tentação de descrever o que já foi feito, em vez do que era necessário.

Uma ressalva importante: os critérios são o registro da conversa, não o substituto dela. Um documento perfeito jogado por cima do muro vale menos que dez minutos de conversa com anotações razoáveis. Se o time só lê os critérios sem nunca discuti-los, o instrumento perdeu a alma.

O formato Dado/Quando/Então

O formato mais conhecido vem do BDD (Behavior-Driven Development) e estrutura cada critério como um cenário de três partes:

• Dado um contexto inicial (o estado do mundo antes da ação);
• Quando alguém faz alguma coisa (a ação);
• Então um resultado observável acontece (o comportamento esperado).

Um exemplo de time de marketing, para a história "como assinante da newsletter, quero me descadastrar com um clique para não receber e-mails indesejados":

Dado que recebi a newsletter no meu e-mail, quando clico no link "descadastrar" no rodapé, então vejo uma página confirmando o descadastro e não recebo mais nenhuma edição.

Dado que já me descadastrei, quando clico no mesmo link de novo, então vejo a mensagem "você já está descadastrado", sem erro.

Repare no segundo cenário: é o caso de exceção, exatamente o tipo de situação que ninguém combina e que gera a discussão no fim da sprint. A grande força do Dado/Quando/Então é essa — ele força a pensar em situações concretas, incluindo as que dão errado. Use esse formato quando a história envolve fluxo com condições: caminhos alternativos, erros possíveis, comportamentos que mudam conforme o contexto.

O formato checklist

Nem toda história precisa de cenários. Quando a entrega é mais estática — uma peça, um documento, uma configuração — uma lista simples de condições verificáveis funciona melhor e é mais rápida de escrever:

História (time de RH): "como novo colaborador, quero receber um kit de boas-vindas no primeiro dia para me sentir parte do time."

• O kit é entregue fisicamente ou por e-mail até as 10h do primeiro dia.
• Contém o guia de boas-vindas atualizado (versão deste ano).
• Contém os acessos: e-mail corporativo, chat e ferramenta de gestão.
• O gestor direto recebe um aviso confirmando a entrega.
• Funciona igual para colaboradores remotos e presenciais.

Cada linha é binária: deu para marcar ou não deu. "Kit caprichado" não entraria nessa lista — caprichado não se verifica; "guia atualizado na versão deste ano" sim. Na prática, muitos times misturam os dois formatos na mesma história: checklist para as condições estáticas, Dado/Quando/Então para os fluxos. Não existe pureza a defender aqui — existe clareza a ganhar. No TeamBOX, os critérios ficam no corpo da User Story dentro da hierarquia Feature → User Story → Task, e a discussão do item guarda o histórico de quem combinou o quê — útil quando alguém pergunta, semanas depois, "por que decidimos assim?".

Exemplos completos de times variados

Marketing — landing page de evento

História: como interessado no evento, quero me inscrever pela landing page para garantir minha vaga.

• Dado que acesso a página pelo celular ou pelo computador, quando ela carrega, então vejo data, local, programação e o formulário sem precisar rolar mais que uma tela no desktop.
• Dado que preencho nome e e-mail válidos, quando envio o formulário, então vejo a confirmação na tela e recebo e-mail de confirmação em até 5 minutos.
• Dado que deixo o e-mail em branco ou inválido, quando tento enviar, então vejo mensagem clara indicando o campo com problema, sem perder o que já digitei.
• Dado que me inscrevo com um e-mail já inscrito, quando envio, então vejo aviso de inscrição existente em vez de inscrição duplicada.

RH — nova política de reembolso de cursos

História: como colaborador, quero solicitar reembolso de curso por um formulário único para não depender de troca de e-mails.

• O formulário está publicado na intranet, na seção de benefícios.
• Pede apenas: curso, valor, comprovante anexado e justificativa curta.
• O gestor direto recebe a solicitação para aprovar ou recusar com comentário.
• O colaborador consegue consultar o status (em análise, aprovado, recusado).
• A política com regras e tetos está linkada dentro do próprio formulário.

Engenharia — recuperação de senha

História: como usuário que esqueceu a senha, quero redefini-la sozinho para não depender do suporte.

• Dado que informo um e-mail cadastrado, quando peço a recuperação, então recebo um link válido por 15 minutos.
• Dado que informo um e-mail não cadastrado, quando peço a recuperação, então vejo a mesma mensagem genérica de envio (sem revelar se o e-mail existe).
• Dado que uso um link expirado, quando tento redefinir, então vejo aviso de expiração e a opção de pedir um novo link.
• Dado que redefino a senha com sucesso, quando faço login com a senha antiga, então o acesso é negado.

Três times, três assuntos, o mesmo padrão: resultado observável, casos de exceção combinados e nenhuma palavra sobre como implementar. Times fora da tecnologia se beneficiam tanto quanto — se o seu contexto é esse, vale ler sobre Scrum fora da TI.

Critérios de aceite não são a Definition of Done

Uma confusão frequente: critérios de aceite valem para um item específico; a Definition of Done (definição de pronto) é a régua de qualidade do time, igual para todos os itens. "O e-mail de confirmação chega em até 5 minutos" é critério de aceite da história de inscrição. "Todo trabalho é revisado por um colega antes de ser publicado" é Definition of Done — vale para a landing page, para o formulário de reembolso e para tudo o mais que o time entregar.

Na prática, um item só está pronto quando passa nas duas réguas. Manter as duas separadas evita retrabalho de escrita (ninguém precisa repetir "revisado por um colega" em cada história) e evita brechas (ninguém "esquece" a revisão porque ela não estava na lista daquele item).

Erros comuns ao escrever critérios de aceite

Critério vago. "A página deve ser rápida", "o processo deve ser simples", "o texto deve ficar bom". Nada disso é verificável — cada pessoa carrega uma régua diferente na cabeça, e a briga só foi adiada para a review. Troque por algo observável: "a página carrega em até 3 segundos no 4G", "o processo tem no máximo 3 etapas", "o texto foi aprovado pela revisão da marca".

Critério que é solução técnica. "Usar cache no servidor", "criar uma planilha compartilhada", "mandar por WhatsApp". Isso descreve como fazer, e o como é decisão de quem executa. Além de amarrar o time a uma solução que talvez não seja a melhor, esconde o resultado que realmente importa. Pergunte "para quê?" até chegar ao efeito observável: "usar cache" provavelmente queria dizer "a página carrega em até 3 segundos".

Critério que é tarefa. "Fazer o layout", "escrever o texto" são passos do trabalho, não condições de aceite — pertencem à quebra em Tasks, não à lista de critérios. Critério descreve o estado final, não o caminho.

Lista quilométrica. Doze critérios numa história é sintoma, não capricho: a história está grande demais. Quebre em duas ou mais — cada uma com sua lista curta — e a sprint inteira fica mais fácil de planejar e de acompanhar.

Escrever depois que o trabalho começou. Critério definido no meio do caminho vira descrição do que já foi feito, e critério definido na review vira munição de discussão. O combinado só protege o time se existir antes do trabalho.

Ignorar os casos de exceção. O caminho feliz todo mundo combina; é o e-mail duplicado, o link expirado e o pagamento recusado que estouram no fim da sprint. Reserve pelo menos um critério para "e se der errado?".

Antes de levar uma história para a planning, passe cada critério neste teste rápido: é binário (dá para responder sim ou não)? É observável (qualquer pessoa do time consegue verificar)? Fala do resultado, não da solução? Foi combinado com quem vai executar? Quatro sins, e a discussão do fim da sprint acabou de perder o motivo de existir.