Uma visão sobre User Stories

Seja sucinta ou cheia de detalhes, user stories são uma ótima ferramenta de comunicação dentro do time.

User stories nunca são uma unanimidade. Tem quem ache que elas devem ser escritas com o máximo de detalhamento possível, tem quem diga que elas nem são tão importantes assim. Acredito que elas são uma ferramenta bastante importante na comunicação com o time de desenvolvimento e com os stakeholders. É onde você pode realmente… contar uma história (oh, really?) e comunicar as necessidades de maneira mais estruturada.

Além disso, elas podem servir como uma documentação a respeito do que está sendo feito. Para consultas futuras isso pode ser útil.

Antes de mostrar como gosto de fazer, não poderia deixar de citar um livro que é um belíssimo ponta pé inicial para quem quer escrever user stories. “User Stories Applied: For Agile Software Development”, de Mike Cohn, é um guia super completo de como construir uma história. Basicamente ele mostra:

1. Como é importante identificarmos os papéis dos usuários. Evitando usuários genéricos damos um contexto mais fechado e criamos empatia. Descrever o incomodo de um paciente na espera de um consultório é mais empático do que dizer que um usuário se incomoda com aquilo. Deixando claro os papéis criamos uma conexão com quem está com determinada dor.
2. Requisitos! É importante te-los bem definidos, mas com a consciência de que eles podem ser alterados.
3. Quebra de histórias. Tudo está definido, agora chega a hora de "fatiar o bolo", quebrar as histórias de modo que entreguem valor o mais rápido possível.

Mas Talita já existe um livro ótimo sobre isso, por que você simplesmente não faz igual?

Porque depende do time.

Para alguns times uma boa reunião para entendimento do problema a ser resolvido tem mais valor do que a US mega detalhada e cheia de critérios de aceite. Existem times que precisam de tudo muito bem detalhado, pois o que não estiver alí descrito não será feito. Outros times não precisam de tudo muito detalhado pois preferem ir tirando dúvidas com o PM ao longo do processo de desenvolvimento da história.

Acho difícil encaixar uma fórmula perfeita para todos os times, pois os contextos de cada um são bem diferentes. Consultorias, por exemplo, podem ser menos flexíveis quanto as US. Startups, se utilizarem US, precisam ser ágeis e lidar muito bem com as mudanças e na maioria das vezes não terão todos os detalhes na US num primeiro momento.

Acredito que menos ou mais criteriosas, as US precisam passar o contexto geral do problema a ser resolvido e os pontos de validação para que ela seja considerada pronta.

Estrutura de uma US

Gosto de utilizar a estrutura abaixo para descrever novas funcionalidades:

Titulo: um resumo da ação que resolverá o problema

"Permitir que o vendedor altere a senha"

Contexto: conta um pouco da dor do usuário e evidencia o problema a ser resolvido

"Atualmente o suporte tem 300 chamados por mês de vendedores solicitando a alteração de senha. Isso representa 40% dos atendimentos, que poderiam ser de outros problemas mais importantes. Portando há a necessidade de permitir que o próprio vendedor altere a senha de acesso para diminuir os atendimentos e dar mais autonomia ao cliente."

Critérios de aceite: é o que vai validar se a história foi feita corretamente e está pronta

"1. Nas configurações de conta, exibir opção Alterar email;

2. Ao clicar em "editar" habilitar os campos Senha atual, Nova senha e Confirmar senha para alterações;

3. Salvar senha após clicar em Alterar Senha;

4. Enviar um email de confirmação de alteração de senha para o vendedor."

A estrutura pode mudar um pouco quando se quer relatar um bug. Ao invés de explorar os critérios de aceite é mais importante focar no resultado esperado ao fazer um fluxo. Gosto da estrutura:

Cenário: descreve um passo a passo sobre como reproduzir um problema

"Vendedor não consegue alterar senha

1. Clicar em configurações;

2. Clicar em Alterar Senha;

3. Informar a senha atual e a nova senha;

4. Clicar em Alterar Senha"

Resultado obtido: é o resultado inesperado obtido após o fluxo ser realizado

"Um erro é apresentado na tela e a senha não é atualizada"

Resultado Esperado: é o resultado obtido quando o fluxo está funcionando corretamente

"A senha é alterada com sucesso e o vendedor recebe um email de confirmação sobre a alteração realizada"

Além de estar bem escrita muitas vezes há a necessidade de complementarmos a User Story com prints, vídeos, documentos mais detalhados, enfim, o céu é o limite. O importante é se certificar de que ela está com todas as informações necessárias para que o time comece o desenvolvimento e que comunique o problema a ser resolvido!

E vocês, como gostam de criar suas User Stories?