Como escrever uma user story?

Afinal de contas, o que é uma user story, ou em bom português, uma história de usuário? Se você chegou até aqui com essa dúvida, ótimo, vamos juntos resolver esse mistério e montar um passo a passo de como fazer isso com qualidade :)

Antes de mais nada, uma das primeiras coisas que você precisa saber sobre o assunto é:

Uma história tem que entregar valor para o usuário, sempre!

Isso significa que se o que você está escrevendo não tiver uma entrega de valor: retorno do investimento, ganho de negócio, atingir algum objetivo estratégico, etc, provavelmente se trata de uma tarefa, e não uma história. Tarefa é um dos passos para desenvolver uma história de usuário ;)

De forma bem objetiva, uma história de usuário é uma maneira sucinta e informal de descrever uma necessidade do usuário. E o modelo mais usado para fazer isso é:

• Como: persona que representa o usuário para quem é direcionada a história. Essa parte é bem importante, pois para garantir o sucesso da entrega de valor, manter o foco no usuário é essencial.
• Eu quero: necessidade / dor do usuário que você pretende resolver.
• Para: aqui entra o valor de negócio, o objetivo que o usuário deseja alcançar e que agregará valor ao produto que está sendo desenvolvido.

Trazendo para a prática, um exemplo da aplicação desse modelo poderia ser:

Como paciente que precisa fazer um exame

Eu quero poder visualizar as datas disponíveis para agendamento do exame

Para que eu possa agendar na data mais conveniente

Ainda no exemplo acima, o valor de negócio implícito na última frase precisa ser medido, então sempre tenha em mente as métricas que você deseja atingir, por exemplo: taxa de conversão de agendamentos, aumento de ROB, NPS, etc. Para isso eu costumo adicionar nas histórias de usuário que escrevo mais um item:

Valor para o negócio: para não ficar repetitivo com a frase "para", aqui é interessante adicionar valores que possam ser medidos, as métricas que você vai acompanhar para medir o sucesso da entrega.

Para fechar uma história de usuário bem escrita, é importante descrever as tarefas que precisam ser executadas, e dar todas as informações necessárias para atingir o objetivo do usuário/negócio, em metodologia ágil esse tópico é chamado de critérios de aceite:

• Regras de negócio
• Fluxogramas, protótipos, layout (todo o material para dar suporte ao desenvolvimento da solução)
• Payloads, endpoints: caso a solução que será desenvolvida integre com outros sistemas é importante trazer um exemplo de como os dados chegam na aplicação (payload), trazer também o endereço que vai chamar o serviço que será integrado (endpoint).

Por fim, uma maneira de avaliar se tudo que você especificou constitui uma boa história de usuário, aplique a regra INVEST:

• Independente: a história de usuário deve ser independente do desenvolvimento de outras histórias.
• Negociável: o escopo deve ser flexível, ou seja, deve estar aberto ao debate com o time e stakeholders, garantindo o envolvimento e a visão de todos.
• Valiosa: como mencionado lá no início, a história TEM que trazer valor para o usuário e o negócio, senão não faz sentido o esforço.
• Estimável: o time precisa ter entendimento do que fazer, e como fazer para medir o esforço, fazendo assim a estimativa.
• Small (pequeno): ela deve caber dentro de um ciclo de entregas, assim como ter baixo grau de incertezas. Em geral histórias grandes dificultam a estimativa do time, pois geram muitas incertezas devido ao longo prazo, e nestes casos é válido repensar a possibilidade de quebrar a iniciativa em mais histórias.
• Testável: tem estreita relação com os critérios de aceite e significa que a solução tem que poder ser validada, e o time tem que ter clareza de quando essa história está concluída, ou seja, atingiu todos os critérios de aceite.

Resumindo, seja objetivo, pense sempre no usuário e no negócio, e foco nas métricas: o que não pode ser medido, não pode ser valorado!