Como você escreve uma user story que os engenheiros realmente acham útil?

Stories úteis carregam o porquê e a fronteira, não só o quê. Mantenha o usuário e o resultado na frase, e depois gaste a maior parte do seu esforço em critérios de aceitação que nomeiem os casos de borda: estado vazio, permissão negada, offline, e o que acontece em caso de falha. Engenheiros não precisam de poesia, precisam saber quando terminaram e quais casos podem ignorar com segurança.

A parte que os engenheiros de fato usam são os critérios de aceitação, então é aí que eu gasto meu tempo. A frase da story carrega o porquê em uma linha, mas depois eu listo os casos: o que acontece com estado vazio, o que um usuário sem permissão vê, o que acontece se a requisição falhar no meio, o que a gente faz numa conexão lenta. Essas são as perguntas que eu receberia no Slack três dias depois, e cada uma delas é uma decisão que eu deveria tomar em vez de um engenheiro chutar às onze da noite. Eu também escrevo o que está explicitamente fora, porque isso corta a folheação a ouro bem intencionada. E eu passo os critérios pelo engenheiro antes de o ticket ser estimado. Leva dez minutos e normalmente revela um requisito que é tecnicamente caro por quase nenhum benefício ao usuário, que eu então posso cortar. Uma story estimada sem essa conversa é basicamente um desejo.