O que faz um bom critério de aceitação, e como você os escreve?

Um bom critério é testável, específico e livre de detalhe de implementação. Alguém deveria ler e dizer passou ou não passou sem interpretar nada. Cubra os caminhos negativos com o mesmo cuidado que o caminho feliz: entrada inválida, permissão ausente, timeout, resultado vazio. Se você não consegue descrever como testaria aquilo, ainda não é um critério, é uma esperança.

Meu teste é se alguém conseguiria ler e marcar passou ou não passou sem me fazer uma pergunta. Se sobrou qualquer interpretação, não está pronto. Então eu evito palavras como adequado, amigável e rapidamente, e troco por algo que dê para verificar de verdade. A outra metade do trabalho são os caminhos negativos, que é de onde vem a maior parte dos defeitos. O que acontece com entrada inválida, o que um usuário sem permissão enxerga, o que acontece quando o serviço a jusante dá timeout, como fica um resultado vazio. Essas são decisões que alguém tem que tomar, e se eu não tomar junto com o negócio, um desenvolvedor vai tomar na correria numa quinta-feira à tarde. Eu também passo os critérios com um desenvolvedor e um testador antes de o trabalho ser puxado. Leva vinte minutos e sempre encontra duas ou três coisas que eu tinha deixado ambíguas.