PREPARAR A TAREFA

Como escrever critérios de aceitação

Bons critérios descrevem um resultado verificável. As decisões em aberto devem continuar visíveis.

3 min de leitura

Para que servem os critérios de aceitação

Os critérios de aceitação definem as condições para aceitar uma alteração. Ajudam quem pede, desenvolve e testa a concordar sobre o resultado. «Usar um hook de React» pode ser uma restrição técnica, mas não descreve um comportamento observável.

Um critério útil indica contexto, ação e resultado que se possa verificar. «A exportação deve ser rápida» não chega: é preciso acordar um objetivo, o volume de dados e a forma de medição. O ticket explica o problema e o âmbito; os critérios definem a aceitação. A Definition of Done da equipa, que pode incluir revisão e testes, não substitui critérios específicos da tarefa.

Requisito confirmado ou pressuposto

«Exportar clientes» não define formato, permissões, colunas ou comportamento quando não há resultados. São decisões em aberto. Uma recomendação pode propor uma opção, mas só passa a requisito depois de confirmada. Distingue no ticket o que está confirmado, proposto e por decidir.

Três exemplos

Funcionalidade: exportar um relatório. Fraco: «O utilizador exporta todos os dados facilmente». Após acordo: «Uma pessoa com permissão Relatórios descarrega um CSV em UTF-8 com todas as linhas abrangidas pelos filtros atuais, incluindo as que não aparecem na página visível». Confirma as colunas e o caso sem resultados antes de acrescentares mais critérios.

Erro: início de sessão. Fraco: «O login volta a funcionar». Melhor: «Com uma conta válida e autenticação de dois fatores, após repor a palavra-passe e introduzir o código correto, a sessão abre e o erro comunicado não aparece». Isto só serve se o erro for reproduzível nessas condições. Regista os passos e o ambiente.

Tarefa técnica: atualização da API. Substitui «passar para v2 sem estragar nada» por uma versão e um ambiente concretos. Verifica se os pedidos de faturação afetados mantêm os campos e códigos acordados e se os testes de integração passam contra v2.

Quando usar Dado / Quando / Então

O formato ajuda quando a ordem e as condições mudam o resultado, por exemplo num fluxo de autenticação. Numa simples mudança de texto acrescenta formalismo. Uma atualização de PHP precisa de versão de destino, integrações afetadas e verificações concretas, não de uma história artificial. Escreve apenas os critérios necessários para decidir se o trabalho está concluído.

Antes de os escreveres, revê o objetivo e as decisões em aberto com a ferramenta de preparação de tarefas. O resultado apoia a conversa, não é uma aprovação automática. Consulta a checklist de prontidão e a comparação com Definition of Ready.

← Voltar aos recursos