Photo by <a href=Andrew Seaman / Unsplash">
Photo by Andrew Seaman / Unsplash

Como escrever uma User Story?

Entenda como construir uma história de usuário de qualidade: critérios de aceite, valor para o negócio e exemplos de como fazer isso na prática

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 — seja ela um retorno do investimento, ganho de negócio, atingir algum objetivo estratégico, entre outros —, provavelmente se trata de uma tarefa, e não uma história. Tarefa é um dos passos para desenvolver uma história de usuário. ;)

Estrutura de escrita de uma história

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 consiste em três pontos:

  • 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 o seguinte:

“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, tenha sempre em mente as métricas que você deseja atingir, como, por exemplo, a taxa de conversão de agendamentos, o aumento de ROB, NPS (Net Promoter Score), ou a que você acredita ser a ideal para trazer uma visão mais clara sobre os resultados alcançados. 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, listar 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, além de 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. Nele, a equipe encontra:

  • 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 chamará o serviço que será integrado (endpoint).

Avaliando a qualidade da sua história com a regra INVEST

Por fim, se você quer 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 em 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 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.

Concluindo

Resumindo, seja objetivo, pense sempre no usuário e no negócio. Importante garantir o alinhamento do time, tirar todas as dúvidas e acompanhar o desenvolvimento de perto, a postura de dono é essencial. Aliás, não esqueça também do foco nas métricas: o que não pode ser medido, não pode ser valorado!

Você sabia que temos conteúdos exclusivos para assinantes do portal?

Além de ter acesso ilimitado a todos os conteúdos, você também pode participar de palestras exclusivas, sessões de Q&A, mentorias em grupo e acesso à descontos em cursos. E claro, assinando você nos ajuda a manter o projeto e aumentar a nossa produção de conteúdo.

Você pode assinar clicando aqui

Inscreva-se no Product Oversee

Textos todas às quartas 7h45 na sua caixa de entrada.
Inscreva-se grátis