Como escrever uma user story matadora

Escrever uma user story é muito mais do que descrever uma tarefa usando uma receita, ela é a base para construção e evolução de um produto usando metodologia ágil (Scrum, Kanban, etc), então saber criá-la da maneira certa é fundamental para a criação de valor na sua entrega.

O que é uma user story?

User story, ou “história do usuário” na tradução literal, é a representação de uma necessidade de negócio, descrita pelo ponto de vista do usuário.

Ela é uma redução do 5W2H, usando apenas os três itens mais importantes: quem, o quê e porque. Há diferentes formas de escrevê-la, desde que contenha os três itens principais, pode ser escrito de qualquer forma. Algumas formas de usar:

“Com o propósito de <porque: valor de negócio ou razão>, como um <quem: papel>, eu gostaria/deveria <o quê: função ou ação>.”

“Eu, enquanto <quem: papel>, quero <o quê: objetivo> para <porque: valor de negócio ou razão>.”

Parece simples, né? Mas não é. São detalhes sutis que fazem toda diferença no resultado, vou tentar explicar cada um desses detalhes por tópicos.

Quem?

Veja um exemplo errado:

“Eu, enquanto gestor, quero que as fotos dos produtos tenham zoom para melhorar a experiência do usuário.”

Essa história pode parecer certa, porém ela contradiz um dos princípios do Manifesto Ágil:

“Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.”

Se o objetivo é satisfazer o cliente, por que a história está no ponto de vista do gestor? Se você está escrevendo histórias assim, há uma grande chance de você estar buscando o feedback para o seu negócio no lugar errado, devemos sempre buscar entregar valor para o usuário final.

Entende-se por usuário final aquele quem vai receber o valor gerado pela história, por isso é importante que a história esteja no seu ponto de vista. A escolha certa do papel é crucial para o início da construção da história.

Uma história bem escrita também especifica com detalhe o usuário. A história é para um usuário logado? Ele é usuário de qual sistema? Ele é um comprador? Ele possui uma persona definida? Quanto mais detalhado quem é esse usuário, mais fácil ficará para criar uma solução adequada.

O quê?

Essa é a parte que as pessoas mais erram. Veja um erro clássico:

“Eu, enquanto usuário, gostaria de uma tela de login para que eu possa acessar de forma segura minhas informações.”

Você alguma vez já viu algum usuário com vontade de fazer login para fazer alguma coisa? Alguém arruma uma camisa de força para esse usuário louco! =)

Esse erro comumente acontece porque estamos sempre querendo criar as histórias já dando a solução do problema, e não é esse o objetivo dela. Como já expliquei, a história é a representação de uma necessidade de negócio, sendo assim, ela não deve representar a solução, a história deve representar o problema do usuário ou negócio.

Normalmente a história é escrita pelo Product Owner, mas quem deve escolher a solução é o time, ou seja, a solução é um processo posterior, que não deve estar presente na criação da história.

Então uma correção justa seria:

“Eu, enquanto usuário, gostaria que somente eu acessasse minhas informações, para que eu possa manter minha privacidade.”

Escrevendo assim permite que o time possa escolher a melhor solução para esse problema, podendo ser um login ou qualquer outra solução que atenda o objetivo da história.

Porque

Não seja leviano em colocar qualquer desculpa como o porquê da sua história, ou pior, deixar sua história sem o motivo dela. O porquê é o que motiva a criação da história, por isso ele é tão importante.

Você pode colocar a dor do usuário ou o valor que história irá gerar para o usuário.

O porquê é usado para priorizar as histórias no backlog, é o guia para o time criar a solução mais adequada e é a partir dele que se cria as métricas para acompanhar se a solução cumpriu seu objetivo.

Este deveria ser o passo mais simples, pois quando você vai escrever uma história normalmente já está com o motivo na cabeça, só tem que transcrever esse motivo de forma clara e objetiva.

Critérios de aceitação

A criação de regras pode facilitar a comunicação e a documentação do que deve ser feito, para isso usa-se criar essas regras junto com a história, que são chamadas de critérios de aceitação, que são critérios (regras) que o usuário espera que sejam atendidos para que ele aceite como pronto.

Vamos usar a história abaixo como exemplo:

“Eu, enquanto comprador de carros, quero poder testar o carro antes de comprar, para poder fazer uma melhor escolha na compra.”

Alguns critérios podem ser definidos:

  • Critério #1: O comprador poderá sair com o carro da concessionária para testar o carro
  • Critério #2: O comprador terá que assinar um termo de compromisso

Apesar de não serem obrigatórios, os critérios ajudam muito em todo o processo, além de poderem ser utilizados posteriormente em testes de aceitação.

INVEST

O acrônimo INVEST ajuda a criar um checklist para assegurar a qualidade da criação das histórias. Os critérios são:

Independente (Independent) – Uma história deve ser independente de outra.

Negociável (Negotiable) – Deve ser aberta a discussão. Recursos negociáveis tiram proveito da confiança: as pessoas podem trabalhar em conjunto, partilhar ideias e compartilhar propriedade do resultado.

Valioso (Valuable) – A história deve entregar valor para o usuário final. Para isso é importante que a histórias sejam fatiadas verticalmente.

Estimável (Estimable) – Deve ser possível estimar um prazo de entrega.

Pequeno (Small) – Boas histórias são bem fatiadas.

Testável (Testable) – O time deve ser capaz de criar testes para a entrega da história.

Se a história não atender um dos critérios do INVEST, a história pode ser negada para ser reescrita.

Tamanho é documento

user storyA história deve ser pequena o suficiente para caber em um sticky note. A intenção da história não é burocratizar, pelo contrário, é promover a colaboração, então a história deve ser um convite para uma conversa, deve promover a comunicação e colaboração.

Se o desenvolvedor ver uma história que o Product Owner colocou no backlog e não souber do que se trata, ele tem que procurar o Product Owner pessoalmente e conversar com ele cara a cara, de preferência perto da história, pois essa é a melhor forma de comunicação.

Documentação não é algo ruim, mas se você precisa procurar um texto e não uma pessoa para alinhar o que precisa ser feito, você não está sendo ágil. Favoreça sempre a colaboração.

Conclusão

Se você já participou de um projeto usando metodologia ágil, se identificou com as questões levantadas aqui? Deixe aqui seu comentário sobre como você tem usado as histórias, do que tem dado certo e errado.

8 comentários em “Como escrever uma user story matadora


  1. Kevin disse:

    Legal Bruno, gostei bastante das dicas e me ajudaram a clarear algumas ideias.

    Gostaria de saber como você escreveria uma história em que a funcionalidade já existe, vou citar um caso que passei recentemente:

    “O usuário tem um botão de anexar arquivos, e ao anexar ele gostaria que todos os arquivos que estão sendo anexados fossem exibidos em uma lista, para que ele pudesse ver e se necessário remover”.

    • Bruno Nardini disse:

      Olá Kevin, tudo bem?
      Desculpa a demora na resposta, não recebi o e-mail da notificação do seu comentário. Mas, vamos lá:
      Não entendi bem sobre “funcionalidade que já existe”, pois se já existe, não há o que fazer, então não há tarefa. Se você se refere em adicionar uma funcionalidade em uma tela já existente, para a história não muda nada.
      Sobre o exemplo que deu, eu mudaria sua história para algo assim:
      “Eu, enquanto usuário, gostaria de poder remover um anexo após adicioná-lo para que eu possa gerenciar melhor os arquivos.”
      Você não pode dar a solução, como falei no texto, você tem que expor o problema, quem dá a solução é a equipe de desenvolvimento. O seu problema, neste caso, não é listar os arquivos, mas sim que você não consegue excluir um arquivo depois que ele foi adicionado, então é isso que você tem que expor na história.
      Na história você considera que a opção de adicionar o anexo já existe, mas não importa se isso já foi feito ou não, pois o foco está no levantamento do problema. A funcionalidade já poderia existir e vc criou o cartão pq tinha o problema, ou você vai ainda criar a funcionalidade e já previu esse problema.
      Fui claro?

  2. Interessante o artigo, a questão da documentação em métodos ágeis de desenvolvimento é sempre voltada mais para o trabalho colaborativo do que criação de documentos extensos.

    Tenho alguns artigos que escrevi sobre métodos ágeis no meu site: http://agiledevelop.blogspot.com.br/

    • Bruno Nardini disse:

      Que bom que tenha gostado. Muito legal seu blog, podemos trocar experiências.

  3. Leandro Bonatto disse:

    Olá Bruno, muito bom o desenvolvimento da user history que postou.
    Gostaria de uma opinião tua: Como escreverias a user history para alteração da NF-e por exemplo. Em outras palavras, possuímos no nosso SW a NF-e 3.10 implementada e como product owner gostaria que software estivesse de acordo com a nova versão da NF-e. Isso é necessário para que nossos clientes possam continuar faturando pelo sistema sem problemas. Porém, um detalhe: Pelas características do nosso SW, não preciso que todas as alterações sejam feitas à exemplo: alterações referentes a produtos controlados pela vigilância sanitária ou combustível não precisam ser implementadas.
    Aguardo retorno ….
    Abraço

    • Bruno Nardini disse:

      Olá Leandro Bonatto, obrigado pelo feedback.
      Isso me parece mais um épico do que história. Você criaria o épico “Atualização da NF-e para versão X”, e associado a este épico você irá criar uma história para cada alteração que deve ser feita. Fazendo assim, você consegue organizar melhor o que precisa ser feito, o time vai conseguir pontuar cada alteração individualmente e você poderá separar essas alterações em sprints.
      Faça sempre o checklist INVEST em todas suas histórias, como sugeri no texto.

  4. Chrístian Carrard disse:

    Muito interessante o artigo Bruno, parabéns. Tenho algumas dúvidas relacionadas à criação de tarefas a partir de uma user story. Existe algum método para ser mais eficaz? Escreve-se a tarefa de forma mais técnica e com maiores detalhes?

    • Bruno Nardini disse:

      Olá, Chrístian! Que bom que tenha gostado.
      As tarefas são criadas pelos próprios desenvolvedores, para controle deles mesmo, pq até mesmo quem sabe o que precisa ser feito são eles. O PO só cria as histórias e os termos de aceite.

Deixe um comentário