Onde colocar detalhes sobre os critérios de aceitação de uma história de usuário?

Nesta postagem do blog sobre critérios de aceitação, o autor explica que bons critérios de aceitação devem:

• Indique uma intenção e não uma solução (por exemplo, "O usuário pode escolher uma conta" em vez de "O usuário pode selecionar a conta em uma lista suspensa")

• São independentes da implementação (idealmente, o fraseado seria o mesmo, independentemente de esse recurso / matéria ser implementado em, por exemplo, web, celular ou sistema ativado por voz)

• São de nível relativamente alto (nem todos os detalhes precisam ser escritos)

E mais detalhes, como:

• O cabeçalho da coluna é "Saldo"
• O formato do saldo rotativo é 99.999.999.999,9 D / CR
• Devemos usar uma lista suspensa em vez de caixas de seleção

deve ser movido para uma documentação interna da equipe ou testes de aceitação automatizados

No entanto , muitas vezes ouço pessoas desaprovando o uso do pepino ou estruturas semelhantes para fazer testes de GUI. Além disso, o uso de uma documentação interna pode gerar muitos problemas devido à falha na atualização da documentação regularmente.

Ainda estou lutando para encontrar uma maneira eficaz de capturar esses detalhes durante a conversa com o cliente.

Eu tenho dois lugares (como o proprietário do produto)

Novos comentários dos clientes podem ser traduzidos em mais histórias, uma mudança de prioridades ou novos detalhes sobre uma história. No registro posterior, tomo notas desses detalhes para histórias futuras que talvez eu esqueça. Estas são notas para mim.

Pouco antes da reunião de planejamento, traduzo o que está na minha cabeça + essas anotações em algo que a equipe pode revisar. Este documento (usamos uma página wiki por épico de usuário) é refinado e finalizado durante o planejamento do sprint, como parte da discussão da história com a equipe.

Eu gosto de capturar 'Constraints' como um 'PS' no final da minha história.

[user] [actions] so that [goal]

Constraints:
- No Touching
- Actions must be gluten free

Essas restrições são limitações que os clientes colocam no meu design, que devem ser consideradas ao avaliar diferentes soluções - preciso conhecê-las com antecedência, por isso dou-lhes muita prioridade.

Gosto de definir testes de aceitação para cada história no estilo BDD como parte da documentação de alto nível (Recursos - Histórias - Testes)

WHEN [preconditions]
GIVEN [trigger action/condition/event/situation]
THEN [expected outcome]

Detalhes específicos, como os mencionados acima, fazem parte de uma maquete de tela na qual o cliente assina; esses detalhes nem sempre são conhecidos antecipadamente, mas, de qualquer forma, se enquadram nas "restrições de design". Quando as maquetes são conhecidas com antecedência, incluo as maquetes e as restrições de design acordadas na documentação de alto nível, porque o cliente deve assinar antes que o trabalho comece.

Portanto, embora conceitualmente separado, não vejo mal em incluí-lo no mesmo documento. Mesmo que não seja necessário para a aprovação do cliente, é conveniente ter todos os requisitos para um recurso / matéria em um só lugar.

Eu adoto uma abordagem bastante pragmática - se um detalhe técnico é importante para a aceitação de uma história, ele deve estar nos critérios de aceitação, independentemente do que dizem alguns posts do blog. Se for realmente importante que o nome da coluna seja "balance", isso deve fazer parte dos critérios de aceitação.

Isso pode levar a critérios de aceitação excessivamente longos. Nesse caso, acho que é necessário ter um critério de aceitação como "deve passar no conjunto de testes X" e é no "conjunto de testes X" onde você coloca todos os detalhes importantes sobre o produto.