O que é Critérios de Aceitação?

Condições para aceitar um resultado existem em diferentes práticas de desenvolvimento. No contexto de User Stories, Mike Cohn discutiu condições de satisfação e testes de aceitação em User Stories Applied, publicado em 2004. Não há um criador único dos critérios de aceitação como ideia geral.

A prática evoluiu com conversas sobre exemplos e automação. O Scrum Guide de 2020 descreve o refinamento de itens do Product Backlog, mas não determina um campo obrigatório chamado critérios de aceitação nem atribui sua escrita exclusivamente ao Product Owner.

Uma descrição curta de necessidade pode orientar a conversa, mas costuma deixar escolhas abertas. “Permitir cadastrar livros”, por exemplo, não informa o que acontece quando um exemplar já existe, qual dado identifica a obra nem o resultado de uma tentativa inválida. Os critérios transformam essas perguntas em condições que o time consegue discutir e verificar.

Comece pelo comportamento, não pela interface. Um critério pode dizer que uma tentativa duplicada não cria outro registro e informa o motivo. Ele não precisa determinar a posição exata de um botão, a cor da mensagem ou a estrutura interna de armazenamento, a menos que esses detalhes sejam relevantes para a necessidade. Isso preserva alternativas de implementação.

Escolha exemplos que diferenciem resultados. Um caso comum, um limite e uma exceção podem revelar interpretações diferentes. Escrever dezenas de cenários semelhantes aumenta manutenção sem ampliar entendimento. Uma lista é suficiente quando deixa a regra clara. O formato Dado, Quando e Então pode ajudar em situações com condições e consequências que exigem exemplo mais preciso. O processo completo de descoberta por exemplos pertence ao verbete BDD.

Torne o critério observável. “A tela deve ser amigável” não informa como alguém verificará o item. “Ao tentar salvar um ISBN já cadastrado, o sistema não cria outro livro e informa a duplicidade” aponta contexto, ação e resultado. Ainda é preciso conversar sobre o que identifica duplicidade e como o usuário deve continuar. Verificabilidade não dispensa entendimento do domínio.

Construa com perspectivas diferentes. O Product Owner pode trazer necessidades e consequências de negócio; Desenvolvedores podem identificar implicações e casos técnicos; pessoas de qualidade e usuários podem revelar dúvidas sobre uso. A composição varia conforme o produto. Delegar toda a escrita a uma função pode esconder informação que outra conhece.

Os critérios podem começar no refinamento do Backlog, mas não precisam ficar congelados antes de iniciar. Quando o time aprende durante a construção, conversa sobre o comportamento e atualiza o acordo. Uma mudança relevante pode afetar escopo e prazo; por isso, deve ficar visível para quem decide.

A Definition of Done trata de qualidade e do estado do Incremento no Scrum. Critérios de Aceitação tratam do comportamento esperado de um item particular. O primeiro conceito é um compromisso formal do Scrum Guide; o segundo é prática complementar. A comparação entre DoD, Definition of Ready e critérios está no verbete da DoD.

Cumprir critérios não exige uma cerimônia de aceite pelo Product Owner na Sprint Review. Os Desenvolvedores precisam criar um Incremento que atenda à DoD; a Sprint Review serve para inspecionar o resultado com stakeholders e adaptar o Product Backlog. Conversas de validação com o PO podem ocorrer durante o trabalho, sem transformar a Review em portão de aprovação.

Testes derivados dos critérios podem apoiar verificação, inclusive automática. Nem todo critério precisa virar um cenário de interface, e uma suíte verde não garante que as regras escolhidas eram as certas. Use exemplos para examinar expectativas com as pessoas que conhecem a necessidade.

Imagine um sistema hipotético de biblioteca em que o bibliotecário cadastra livros para empréstimo. O item inicial diz apenas “cadastrar novo livro”. Em uma conversa com 4 pessoas, o time identifica três dúvidas: como reconhecer obra duplicada, quando criar outro exemplar e o que fazer se faltar ISBN.

O grupo combina critérios iniciais. Se o ISBN não existe, o cadastro cria uma obra e seu primeiro exemplar. Se o ISBN já existe, a ação de adicionar um exemplar aumenta a quantidade da obra existente, sem duplicar seus dados bibliográficos. Se o campo ISBN obrigatório estiver vazio, a tentativa não altera o catálogo e informa a falta ao usuário.

Antes, duas pessoas poderiam implementar comportamentos diferentes para o mesmo título: duplicar a obra ou acrescentar exemplar. Depois, o item tem três resultados observáveis e uma pergunta aberta: como tratar livros publicados sem ISBN? O time leva essa pergunta a quem conhece a política da biblioteca antes de inventar uma regra.

Num teste inventado, o catálogo começa com 1 obra e 2 exemplares para um ISBN. Ao adicionar um exemplar, passa a 1 obra e 3 exemplares. A contagem exemplifica o resultado esperado. Não representa um caso real da K21 nem substitui a discussão de permissões, auditoria e outros requisitos do serviço.

Os critérios devem ser revisados se a política da biblioteca mudar. O time pode acrescentar exemplos relevantes e retirar redundâncias. O objetivo é manter clareza suficiente para construir e verificar o item, sem tentar escrever antecipadamente uma especificação completa de todo o catálogo.

Cursos K21 recomendados