Seus critérios de aceitação devem ser escritos como Dado/Quando/Então ou como checklists?

Você deve especificar seus critérios de aceitação como Dado/Quando/Então

Dado/Quando/Então é  uma forma quase onipresente* de especificar cenários de usuário:

Dado uma condição
Quando faço alguma ação
Então espero algum resultado

Se você escreve seus critérios de aceitação neste formato, isso não só provém uma estrutura consistente, mas se seus testes de aceitação automatizados também são especificados no formato Dado/Quando/Então, então isso traduz critérios de aceitação em testes de aceitação muito eficientes.

Os seus critérios de aceitação são menos propensos a serem nebulosos como se pensa quando seguindo este formato consistente, com uma pré-condição, ação e  resultado esperado.

* Este formato foi escrito pela primeira vez por Dan North, em 2007, e alguma vezes é referenciado (incorretamente) como a linguagem Gherkin, que é específica da ferramenta Cucumber.

Você deve especificar seus critérios de aceitação como checklists

Ter os critérios de aceitação especificados para uma história de usuário em um formato de checklist faz dos critérios de aceitação claros e concisos, visto que nada mais é necessário. Cenários do tipo Dado/Quando/Então podem ser verbosos e difíceis de ler em um cartão de história de usuário.

Isso também significa que eles são fáceis de individualmente serem marcados como completos enquanto os programadores implementam a funcionalidade (em uma ferramenta como o Trello).

O maior benefício é que checklists de critérios de aceitação não podem ser transferidos diretamente da história de usuário à um teste de aceitação automatizado. Isto é importante porque os critérios de aceitação das funcionalidades não devem replicar histórias de usuário: uma história de usuário é uma mudança para um sistema, uma funcionalidade é uma coleção de coisas que ele faz. Então, ter uma funcionalidade para cada história de usuário é um desastre, o que é mais provável de acontecer se os critérios de aceitação estão no formado Dado/Quando/Então.

Ter seus critérios de aceitação em formato de checklists também significa que há algum pensamento humano sobre como implementar um testes de aceitação. Pode ser que um cenário de testes de aceitação cubra três itens de critérios de aceitação do checklist, que é como deveria ser feito, não simplesmente um mapeamento um para um, o que pode acontecer quando se usa o formado Dado/Quando/Então para ambos critérios de aceitação e testes.

Tradução/adaptação de Pride and Paradev, de Alister Scott.

Mais uma vez, tudo depende do contexto, e também, de quem consome  a especificação.

Nos últimos meses já trabalhei em projetos em que escrevíamos critérios de aceitação no formato Dado/Quando/Então e no momento estou trabalhando em um projeto onde os critérios de aceitação são escritos no formato de checklists.

No primeiro caso, o ideal é quando o cliente, PO ou stakeholder participa da especificação das histórias de usuário e também da validação dos critérios de aceitação, ou mesmo de sua definição. Já no segundo caso, quando tal documentação nem mesmo chega ao cliente final e é utilizada somente como suporte ao time para saber quando as coisas estão prontas, isto é o suficiente.

Não temos que fazer as coisas simplesmente por fazer e sim fazer as coisas que fazem sentido.

Mudando um pouco de assunto, e sobre os boards, são melhores quando físicos ou virtuais?

Next week we talk about this. =D