O formato padrão de user story é, "Como beneficiado, Eu quero objetivo". Para algumas user stories, entretanto, este modelo simples dá errado quando se trata de descobrir quem deve ser indicado no campo beneficiado.
Por exemplo, em uma thread recente no mailing list do Scrum Development, Kevin Krac foi perguntado sobre a seguinte user story:
O Product Owner tinha um pensamento sobre uma história que se tratava de mudar o número do telefone onde o cliente poderia ligar depois de fazer uma compra. Agora, o número de telefone do departamento de Marketing está listado no e-mail enviado para o cliente, mas o Product Owner pensou que seria mais sensato colocar lá um número de telefone de um representante de vendas em seu lugar.
Quem deveria ser o campo beneficiado nesta user story em particular? O P.O.? Um membro do departamento de marketing? Um representante de vendas? Ou outra pessoa?
Por que incluir um campo beneficiado nas user stories? Don MacIntyre me deu uma razão: "Eu descobri que identificar claramente o papel do beneficiário ajuda o P.O a chegar a uma proposta com valor mais claro - isso o ajuda a priorizar melhor a story." Nesta story, entretanto, não está claro quem é o beneficiado quando o time de desenvolvimento finalizar o trabalho.
Ron Jeffries vê pouco valor em aderir ao formato de story padrão:
O que está no cartão é pouco relevante em tudo: eu seria a favor de algo como "Substituir o número de telefone do marketing para o cliente, pelo número do representantes de vendas.
[...]
Pensar é importante. Escolher as histórias mais valiosas é importante. Explicar para a equipe que está finalmente decidido é importante. Ter testes concretos para ter certeza que aquilo funciona é importante.
O que está escrito no cartão é menos importante do que qualquer uma delas.
Mike Cohn, entretanto, vê algumas vantagens no formato padrão de user stories. As vantagens que ele vê são:
- Colocar histórias de usuários na primeira pessoa ("Como ... Eu quero ...") ajuda os desenvolvedores e outras pessoas do time identificar-se com os beneficiários do trabalho que estão fazendo.
- Estruturar todas as histórias da mesma forma ajuda o P.O. priorizar sem a necessidade de analisar mentalmente o texto de cada user story.
Para que o formato padrão funcione para stories não padronizadas, Mike Cohn tem um conjunto de dicas:
Uma boa user story pode ser sobre qualquer skateholder do sistema. E a história pode, facilmente, ser algo diferente de "querer" como em "Como um comprador, tenho mostrado produtos complementares quando eu começar a fazer check-out." Ou, "Como um usuário, sou forçado a alterar a minha senha a cada 90 dias." Assim, nem todas as histórias precisam ter a palavra "querer" neles.
Preencher lacunas em um modelo de user story, por mais excelente que esse modelo seja, não vai fazer o trabalho duro que precisa ser feito. As chaves para o sucesso de uma user story são, como Ron Jeffries coloca, "Cartão de Confirmação, conversação". Ou seja, fazer um cartão com o texto apenas o suficiente para identificar o requisito (a "história de usuário"), que tenha apenas a comunicação suficiente entre o cliente e os programadores, capaz de torná-los aptos a codificar essa tarefa com êxito, e confirmar o resultado do trabalho realizado por meio de um teste de aceitação.
E você leitor? Qual tipo de user story você escreve?