Se tem Método Ágil, tem história de usuário
Histórias de Usuário sem dúvida nenhuma é a ferramenta mais utilizada para levantar requisitos ágeis. Independente do Método Ágil que você utiliza, ou seja, não importa se é Kanban, Scrum, XP, Lean Startup…. é quase garantido que sempre irá existir uma lista de histórias de usuário.
Antes de tudo, você sabe de onde vieram as histórias de usuário?
Elas surgiram no XP (extreme programming) no final da década de 80, onde o seu principal objetivo era representar o desejo do usuário por algum funcionalidade. Além de representar um desejo, as histórias de usuário também deveriam ser de fácil priorização.
É um fato que assim como outras técnicas do XP, como TDD e Pair-Programming as users stories também se tornaram bem difundidas em quase todos as metodologias ágeis.
Hoje elas são sem dúvida nenhuma de grande importância para qualquer Product Owner, mas será que todo PO ou Gestor de Produto sabem escrever uma boa história de usuário?
Acompanhem agora 08 dicas de como escrever uma história de usuário que realmente seja excelente e ajude o seu time e cliente em busca do produto perfeito.
01. Foco no cliente ou usuário final
Histórias de Usuário – Foco no cliente
Como já diz no próprio nome é um história de usuário, logo, o foco deve estar no que seu cliente ou usuário final desejam.
Se por algum motivo não está focado no seu usuário, ou nem conhece o seu usuário, as chances são de você escrever user stories totalmente sem valor e que não irão agregar nada para o seu produto ou projeto.
Se quer escrever boas histórias de usuário, o foco deve estar no cliente usuário final e não no que você acredita que ele deseja.
02. Utilize personas, elas vão te ajudar
Histórias de Usuário – Personas
Se você não conhece o seu cliente ou usuário final, utilizar personas com certeza irão te ajudar muito no momento de descobrir nos histórias de usuário.
Personas são personagens que irão representar o seu cliente, ou seja, você irá criar um personagem que tenha as mesma características do seu usuário e a partir dessas definições levantar os desejos dessas personas.
É comum um produto ter mais de uma persona, isso sem dúvida vai facilitar. Uma boa dica é combinar personas com o story-mapping, essa junção vai te ajudar muito.
03. Histórias de Usuário são INFORMAIS
Se em algum momento você achou que user stories irão substituir a documentação de todo o projeto, me desculpe, mas você está pensando totalmente errado.
Histórias de Usuário são informais e servem apenas para representarem os desejos dos seus usuários e clientes, nada mais que isso.
Logo, se você quer escrever boas histórias de usuários, as mantenha como conversar informais, que irão mudar algumas vezes ainda.
04. Devem representar valor de negócio
Histórias de Usuário – Valor de Negócio
Se por um lado histórias de usuário são informais, por outro, elas devem representar valor de negócio. Ou seja, elas deve ter um motivo para existirem.
É muito comum existem user stories sem o PORQUE preenchido.
Logo, se quer escrever histórias de usuário realmente boas e úteis, deixe claro o valor de negócio.
05. História de Usuário deve ser INVEST
Histórias de Usuário – INVEST
Segundo Mike Cohn uma user story só é considerada válida se seguir todas as características do modelo INVEST. E eu concordo com ele, acredito inclusive que isso deveria ser aplicar a todos os modelos de requisitos ágeis que possam existir.
Mas o que é INVEST? A palavra nada mais é do que a junção das iniciais de Independente, Negociável, Valiosa, Estimável, Pequena (Small) e Testável. Vamos detalhar melhor:
- Independente
- Toda história de usuário deve ser independente de outras histórias.
- Negociável
- Lembre-se toda história de usuário é apenas um desejo do usuário, logo, pode considerar ela sendo apenas um ponto de partida. Portanto, deve ser totalmente negociável.
- Valiosa
- Deve representar valor de negócio, sempre. Sem valor de negócio não faz sentindo existir, é simples assim.
- Estimável
- O time deve ser capaz de estimá-la.
- Pequena (Small)
- Deve ser pequena e assim reduzindo as incertezas e dificuldades de estimativas.
- Testável
- Todas histórias de usuário devem ser testáveis, ou seja, deve ser possível validar se atingem os critérios de aceitação.
Se deseja escrever um boa história de usuário aplique o INVEST.
06. Comece as grande e termine com as pequenas
Para chegar a boas histórias de usuário, a minha dica é: Comece identificando os Épicos.
Épicos nada mais são que grandes histórias de usuários, por exemplo, veja a seguinte história:
Como usuário gostaria de pagar minha compra para possa receber os produtos.
Essa história acima é um Épico, perceba que para o usuário realizar o pagamento ele terá que realizar outras ações como, escolher a forma de pagamento, se selecionar cartão de crédito com certeza ele deverá informar se vai dividir ou não.
Enfim, perceba a quantidade de histórias de usuário que podem se derivar do nosso exemplo, portanto, começar pelos épicos é um excelente maneira de encontrar boas novas histórias de usuário.
07. Mantenha as Histórias de Usuário visíveis
User Stories existem para promover a colaboração e conversas sobre elas mesmas, portanto, não as deixe “escondidas” em uma planilha do google drive, ou em uma ferramenta qualquer.
Uma excelente técnica, que já utilizei é o Story Board, que nada mais é do que um canva, com três colunas que são:
- Ideias: Onde o PO adiciona novas ideias que surgem.
- Validação de Valor: Histórias de Usuário que estão em validação de valor de negócio.
- Priorizadas para PB: Histórias de Usuários onde se identificou valor de negócio.
Mantenha suas histórias de usuário vivas e visíveis.
08. Não confie apenas nas histórias
É como já falei mais a cima, histórias de usuário são informais e não devem substituir documentação. Logo, não devemos “acreditar” apenas nas users stories e assim deveremos procurar o que vai ser necessário para completa-lás.
Seja um diagrama de sequencia, um template de jornada de usuário ou um protótipo… a dica é: Complete a sua história de usuário com o que julgar necessário e que agregue valor para o seu time de desenvolvimento.
Pra fechar…
Minha dica final é: Utilize Histórias de Usuário, eu particularmente ainda não encontrei um modelo tão útil para o desenvolvimento de produtos e projetos. Assim, recomendo a sua utilização, mas desde que siga as boas práticas.
Agora como você vai estimar, ou priorizar é outra história, mas para ter sucesso com as estimativas e priorizações serão necessárias boas histórias de usuário.
