Histórias e seus erros mais comuns

Product Managers de diferentes tipos de produtos precisam aprender a escrever boas histórias de usuários, também conhecidos como user story

Histórias e seus erros mais comuns
Photo by Jo Szczepanska / Unsplash

Product Managers de diferentes tipos de produtos precisam aprender a escrever boas histórias de usuários, também conhecidos como user story. Contudo, o primeiro passo é entender o que é uma user story.

A User Story possui três aspectos críticos, chamados de “os três C’s”: o Cartão, as Conversas e a Confirmação. Veremos em seguida o que cada um desses aspectos significa (Cohn, 2004).

Para escrever um bom Cartão de User Story há três parâmetros da necessidade da pessoa usuária: “quem”, “o quê” e “por quê”.

O QUEM ajuda a identificar o usuário ou persona para qual se destina a história, criando uma identificação mental do usuário. O O QUÊ representa o problema, a real necessidade do usuário, já o POR QUÊ mostra qual o benefício está sendo entregue com a história, ou seja, seu valor.

A parte da Conversa sobre User Story tem como objetivo trazer uma visão compartilhada do que é necessário para que a funcionalidade gere valor de negócio e retorno ao investimento.Este é um item realizado durante o refinamento, onde os detalhes da solução e do negócio são discutidos, como também os critérios e testes de aceitação.

A Confirmação corresponde às regras que estabelecem como a funcionalidade deve se comportar uma vez implementada, ou seja, são os critérios e os testes de aceitação.

Posso destacar cinco erros erros comuns ao escrever das histórias de usuários.

  1. Story mania: Algumas equipes acabam escrevendo tudo como histórias, em alguns casos resultam em histórias estranhas - histórias que capturam o design da interface do usuário, interações complexas do usuário e requisitos técnicos; ou esses aspectos são simplesmente ignorados.
  2. Usuário anônimo: Algumas histórias não especificam um usuário ou persona, desta forma fica pouco claro para quem se destina o benefício da história e se ela realmente resolverá algum problema.
  3. Detalhes desastrosos: Algumas histórias são muito amplas e com muitos detalhes, outra são grandes e vagas demais. A orientação é começar por um Épico, ele permite que capture uma ideia sem detalhes, os detalhes ficaram por cada história que faz parte do épico.
  4. Entrega da história: Alguns Product Owner, escrevem cuidadosamente suas histórias e a entregam a equipe durante o planejamento da próxima sprint, contudo realizar a escrita em conjunto permite debater melhor o problema e entendimento da melhor solução, sendo feito isto durante a Conversa.
  5. Crise de critérios: Existem histórias escritas sem critérios de aceitação ou ainda com critérios confusos ou redundantes. A idéia por trás dos critérios de aceitação é simples: eles permitem que você descreva as condições que devem ser cumpridas para que a história seja concluída, para que possa ser exposta aos usuários e às outras partes interessadas. Isso garante que você obtenha feedback e / ou recursos de versão e ajuda a equipe a planejar e acompanhar seu trabalho.

Esse modelo é amplamente utilizado, e é uma maneira simples de comunicar como um usuário utilizará o produto para resolver seu problema e usufruir dos benefícios do produto.

Existem várias outras formas de escrever histórias do ponto de vista de usuários e nada impede que você e o time que participa inventem formatos que mais se adequam a realidade de vocês.

Referências: