O que é e como escrever histórias de usuários da forma correta

Para muitas equipes de desenvolvimento de software que buscam o agile, a ideia de escrever histórias de usuários pode parecer outra “coisa” que acumula agile em cima de suas cargas de trabalho já ocupadas. Ouvimos você, também estamos ocupados! Mas se você está lendo esta postagem do blog, significa que definitivamente tem algum tempo de sobra para escrever histórias de usuários. E bons nisso!

Vamos começar observando o que é e o que não é uma história de usuário.

Como escrevemos histórias de usuários?

Uma história de usuário geralmente segue a seguinte ‘equação’:

Como um <tipo de usuário>, quero <algum recurso> para que <algum motivo>

Vamos decompô-lo um passo adiante;

• Como um <tipo de usuário> – este é o QUEM. Para quem estamos construindo isso? Quem é o usuário?
• Gostaria de <algum recurso> – este é o QUÊ. O que estamos construindo? Qual é a intenção?
• Para <alguma razão> – este é o PORQUÊ. Por que estamos construindo? Qual é o valor para o cliente?

Vejamos alguns exemplos simples:

Como um cliente de internet banking
gostaria de ver um saldo móvel de minhas contas do dia a dia, para
para possa controlar meus gastos após a aplicação de cada transação

OU

Como administrador
gostaria de  ser capaz de criar outros administradores para determinados projetos, para
para eu possa delegar tarefas com mais eficiência

INVEST

INVEST diz que uma boa user story possui seis características:

Independent

Histórias são mais facilmente trabalhadas quando forem independentes, ou seja, quando é possível sua implementação em qualquer ordem. Talvez essa seja a característica mais difícil de alcançar totalmente.

Negociable

Histórias não são contratos para implementar features; boas histórias captam a essências e não os detalhes de uma feature. Assim que for definida a essência, os detalhes são negociados com o Product Owner e não definidos por ele.

Valuable

A premissa básica de uma história é que ela agregue valor ao produto, para o cliente. Quando começamos a quebrar demais as histórias, temos que ter o cuidado de não transformá-la em algo que entregue apenas uma parte da feature.

Estimable

Não precisa ser algo exato; o time não precisa acertar sempre; mas o time precisa ser capaz de estimar uma história. Histórias estimáveis pode ser negociada, ninguém consegue estimar uma história que não entende. Entendo que esta seja a característica chave de uma boa user story, por que está intimamente ligada a outras.

Small

Boas histórias de usuários são pequenas. Elas entram no acordo entre Time e Product Owner sobre o tamanho máximo de uma história dentro da Sprint. Além disso, quando as histórias são menores, há chances maiores de ter uma estimativa mais precisa. É o típico caso de quando o Time joga para o alto a estimativa de uma história “por não entender o que implicaria sua implementação”. Se o time usar essa frase na planning, significa que a história deve ser revista.

Testable

É preciso testar! Sempre! Testabilidade sempre foi uma característica de bons requisitos; o mesmo é plenamente aplicável à user stories. Se o cliente não sabe como testar algo, significa que ou a história de usuário não está clara o bastante ou que ela não contém algo que acrescente valor aos olhos do cliente.

Critérios de Aceite para Histórias de Usuários

As histórias de usuário permitem que as equipes tenham uma mão sobre as necessidades, desejos e valores de seus clientes e outra, sobre as atividades que precisam realizar para fornecer esse valor.

O link que une essas duas coisas é o critério de aceitação.

Metas de critérios de aceite

Os critérios de aceite são definidos para:

• Esclarecer o que a equipe deve construir antes de começar a trabalhar;
• garantir que todos tenham um entendimento comum do problema / necessidade do cliente;
• Ajudar os membros da equipe a saber quando a história está completa;
• Ajudar a verificar a história por meio de testes automatizados.

Vejamos um exemplo de uma história de usuário completa com critérios de aceitação;

Como um potencial participante da conferência, gostaria de  poder me inscrever na conferência online, de para inscrição seja simples e sem papel.

Critérios de aceite

• Formulário de Presença em Conferência;
• Um usuário não pode enviar um formulário sem preencher todos os campos obrigatórios (nome, sobrenome, nome da empresa, endereço de e-mail, cargo, informações de faturamento);
• As informações do formulário são armazenadas no banco de dados de registros;
• A proteção contra spam está funcionando;
• O pagamento pode ser feito via Paypal, Cartão de Débito ou Crédito;
• Um e-mail de reconhecimento é enviado ao participante após o envio do formulário.

Os critérios de aceite NÃO devem incluir:

• A revisão do código foi feita;
• Não bloqueador ou problemas principais;
• Teste de desempenho realizado;
• Aceitação e teste funcional realizados.

Por quê?

Seus critérios de aceite não devem incluir nenhum dos itens acima pois sua equipe já deve ter um entendimento claro do que sua Definição de Feito (DoD).

Dicas para escrita de boas Histórias de Usuários

1 – Usuários vêm primeiro

Como o nome sugere, uma história de usuário descreve como um cliente ou usuário emprega o produto; é contado da perspectiva do usuário. Além do mais, as histórias de usuário são particularmente úteis para capturar uma funcionalidade específica, como pesquisar um produto ou fazer uma reserva.

A figura a seguir ilustra a relação entre o usuário, a história e a funcionalidade do produto. Se você não sabe quem são os usuários e clientes e por que eles gostariam de usar o produto, não escreva nenhuma história de usuário.

Realize primeiro a pesquisa de usuário necessária, por exemplo, observando e entrevistando usuários. Caso contrário, você corre o risco de escrever histórias especulativas baseadas em crenças e ideias – mas não em dados e evidências empíricas.

2 – Use Personas para descobrir as histórias certas

Uma ótima técnica para capturar seus insights sobre os usuários e clientes é trabalhar com personas. Personas são personagens fictícios que se baseiam no conhecimento de primeira mão do grupo-alvo.

Geralmente consistem em:

• Um nome;
• Uma imagem;
• Características, comportamentos;
• Atitudes relevantes;
• Objetivo.

O objetivo é o benefício que a persona deseja alcançar ou o problema que o personagem deseja ver resolvido com o uso do produto. Mas há mais:

Pergunte a si mesmo que funcionalidade o produto deve fornecer para atender aos objetivos das personas

3 – Crie histórias de usuário de forma colaborativa

As histórias de usuários são uma técnica leve que permite que você se mova rapidamente. Eles não são uma especificação, mas sim uma ferramenta de colaboração.

As histórias nunca devem ser entregues a uma equipe de desenvolvimento. Em vez disso, eles devem ser inseridos em uma conversa:

Isso permite que você capture apenas a quantidade mínima de informações, reduza a sobrecarga e acelere a entrega. Você pode levar essa abordagem mais longe e escrever histórias de forma colaborativa como parte do processo de preparação do Backlog do Produto.

Isso alavanca a criatividade e o conhecimento da equipe e resulta em melhores histórias de usuários.

Se você não pode envolver a equipe de desenvolvimento no trabalho da história do usuário, deve considerar o uso de outra técnica mais formal para capturar a funcionalidade do produto, como casos de uso.

4 – Mantenha suas histórias simples e concisas

Escreva Histórias de Usuários de modo que sejam fáceis de entender. Mantenha-os simples e concisas.

Evite termos confusos e ambíguos e use voz ativa. Concentre-se no que é importante e deixe o resto de fora.

O modelo a seguir coloca o usuário ou cliente modelado como uma persona na história e torna seu benefício explícito. É baseado no popular template de Rachel Davies, mas substituí o papel do usuário pelo nome da persona para conectar a história com a persona relevante.

Use o modelo quando for útil, mas não se sinta obrigado a aplicá-lo sempre. Experimente diferentes maneiras de escrever suas histórias para entender o que funciona melhor para você e sua equipe.

5 – Comece com épicos

Um épico é uma história grande, esboçada e de granulação grosseira. Geralmente, é dividido em várias histórias de usuário ao longo do tempo, aproveitando o feedback do usuário sobre os primeiros protótipos e incrementos do produto.

Você pode pensar nisso como um título e um espaço reservado para histórias mais detalhadas.

Começar com épicos permite que você faça um esboço da funcionalidade do produto sem se comprometer com os detalhes, e isso particularmente é útil para descrever novos produtos e recursos.

Também reduz o tempo e o esforço necessários para integrar novos insights. Se você tiver muitas histórias de usuário detalhadas na lista de pendências do produto, geralmente é complicado e demorado relacionar o feedback aos itens apropriados e isso acarreta o risco de introduzir inconsistências.

6 – Refine as histórias de usuário até que estejam prontas

Divida seus épicos em histórias menores e detalhadas  até que estejam prontas, claras, viáveis ​​e testáveis.

Todos os membros da equipe de desenvolvimento devem ter uma compreensão compartilhada do significado da história, não devendo ela ser muito grande e caber confortavelmente em um Sprint.

Deve haver uma forma eficaz de determinar se a história está terminada.

7 – Adicionar Critérios de Aceitação

Conforme você divide os épicos em histórias menores, lembre-se de adicionar critérios de aceite, pois eles complementam a narrativa e permitem você descrever as condições que devem ser atendidas para que a história seja feita.

Tais critérios enriquecem a história, as tornam testável e garantem que a possam ser demonstrada ou divulgada para os usuários e outras partes interessadas. Como regra prática, utilize de de três a cinco critérios de aceitação para histórias detalhadas.

8 – Use cartões de papel

As histórias de usuário surgiram na Extreme Programming (XP), e a literatura inicial do XP fala sobre cartões de história em vez de histórias de usuário. O motivo é simples:

as histórias de usuários foram capturadas em cartões de papel.

Essa abordagem oferece três benefícios:

• Primeiro, os cartões de papel são baratos e fáceis de usar;
• Segundo, eles facilitam a colaboração;
• E, terceiro, os cartões podem ser facilmente agrupados na mesa ou parede para verificar a consistência e integridade e para visualizar as dependências.

Mesmo que suas histórias sejam armazenadas eletronicamente, vale a pena usar cartões de papel ao escrever novas histórias.

9 – Mantenha suas histórias visíveis e acessíveis

As histórias querem transmitir informações. Portanto, não as oculte em uma unidade de rede, na selva da intranet corporativa ou em uma ferramenta licenciada. Torne-os visíveis, por exemplo, colocando-os na parede.

Isso estimula a colaboração, cria transparência e torna-se óbvio quando você adiciona muitas histórias muito rapidamente, pois o espaço na parede fica acabando.

Uma ferramenta útil para descobrir, visualizar e gerenciar suas histórias de usuários é minha tela de produto  mostrada abaixo.

10 – Não confie exclusivamente nas histórias de usuários

Criar uma ótima experiência do usuário (UX) requer mais do que histórias de usuário . As histórias de usuário são úteis para capturar a funcionalidade do produto, mas não são adequadas para descrever  as jornadas do usuário e  o design visual .

Portanto, complemente as histórias do usuário com outras técnicas:

• Mapas de histórias;
• Diagramas de fluxo de trabalho;
• Storyboards;
• Esboços e maquetes.

Alguns erros comuns

Story Mania

Alguns Product Owners e equipes gostam tanto de histórias de usuários que tudo é expresso como uma história. Isso resulta em algumas bastante 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 esquecidos.

Como qualquer técnica, a escrita da histórias de usuários tem seus pontos fortes e limitações. Elas são particularmente adequadas para capturar a funcionalidade do produto e, quando aplicadas de maneira adequada, os requisitos não funcionais.

Mas o design da interface do usuário e as complexas interações são melhor descritos por outras técnicas, incluindo esboços de design, maquetes, cenários e storyboards.

Complemente suas histórias de usuário, portanto, com outras técnicas, e não se sinta obrigado a usar apenas histórias.

Usuário anônimo

Uma história de usuário conta a história de alguém interagindo com o produto. Algumas histórias, no entanto, omitem totalmente o beneficiário ou falam sobre um usuário misterioso como em “Como usuário, eu quero …”

Mas se não está claro quem é o usuário:

• Por que a história deveria ser desenvolvida?
• Como podemos ter certeza de que a história beneficiará alguém?

Certifique-se de que todas as suas histórias tenham um usuário ou cliente claro. Como gosto de trabalhar com personas, uso personas em minhas histórias (em vez de papéis de usuário). Isso conecta cada história à persona certa e me permite entender se e até que ponto a história atende à necessidade ou objetivo da persona.

Detalhes desastrosos

O diabo está nos detalhes: algumas histórias de usuários são muito grandes e vagas para a equipe entender e implementar. Outros contêm muitos detalhes ou até prescrevem uma solução.

Para obter o nível de detalhe correto, comece com histórias grandes chamadas de épicos . Os épicos são como marcadores: eles permitem que você capture uma ideia sem se comprometer com os detalhes.

Em seguida, divida um épico em histórias de usuário mais detalhadas, envolvendo a equipe de desenvolvimento e aproveitando o feedback do usuário sobre os primeiros incrementos do produto.

Transferência de história

Alguns Product Owners escrevem histórias de usuário e as fornecem à equipe de desenvolvimento na reunião de Planejamento do Sprint. Essa transferência geralmente não é ideal, pois desperdiça as ideias e o conhecimento da equipe. As histórias podem, portanto, ser inadequadas, difíceis de entender, inviáveis ​​e não testáveis.

As histórias de usuário, no entanto, não devem ser documentos independentes. Devem ser complementados por uma conversa entre o Product Owner e a equipe, ou melhor ainda: escritos de forma colaborativa.

Uma história quer capturar o essencial e não especificar todos os detalhes. O último seria difícil para novos recursos e muito lento e caro em um contexto ágil / enxuto. A escrita da histórias de usuários deve ser um esforço de equipe, em que o product owner e a equipe de desenvolvimento criam as histórias juntos.

Reserve tempo para um workshop colaborativo do Product Canvas ou reunião de preparação de listas de pendências , principalmente ao desenvolver um novo produto ou novos recursos.

Crise de critérios

Os critérios de aceite são talvez a parte mais incompreendida das histórias. Já vi histórias detalhadas sem critérios de aceitação, critérios que reafirmam a narrativa e critérios que ocultam novas histórias ou mesmo contêm fluxos de trabalho inteiros.

Os dois últimos erros são exemplificados pela seguinte história (a narrativa está no cartão à esquerda, os “critérios de aceitação” à direita). A ideia por trás dos critérios de aceitação é simples:

Isso garante que você reúna feedback e / ou recursos de lançamento e ajuda a equipe a planejar e rastrear seu trabalho: Os critérios enriquecem a história e a tornam mais precisa e testável.

Referências

• https://bit.ly/2TuBb1v
• https://bit.ly/37LOjaR
• https://bit.ly/2TyjttP