Como escrever boas user stories

Qualquer pessoa minimamente familiarizada com agilidade sabe o que é uma user story. O problema é quando algumas pessoas acham que basta "especificar" uma user story que, em alguns dias, o software vai se materializar e estar pronto pra ser usado.

Quem dera o desenvolvimento de software funcionasse dessa forma.

Dependendo do seu contexto, ter uma história muito grande e/ou com vários cenários diferentes é problemático. Especialmente em startups que precisam ser sempre ágeis. Já vi muita gente usando o famoso Gherkin Style, hoje em dia eu procuro não trabalhar com isso pra tentar ser mais ágil. Por isso resolvi escrever esse artigo pra ajudar gerentes de produto ou analista de negócios a serem mais ágeis e menos burocráticas.

Cena clássica entre Gerentes de Produto e Desenvolvedores

Você recebe uma demanda e então escreve a User Story e chega pra falar com os desenvolvedores

“13 pontos?!”, você exclama.

“Tem muita coisa que precisa ser feita pra concluir essa história, e ainda assim nós não temos tanta certeza do que vai acontecer quando implementarmos essa parte X. Nós nunca fizemos alguma coisa desse porte com esse software. Precisamos quebrar mais as histórias!”, respondem os desenvolvedores

Você: “Por que eu faria isso? Eu preciso da funcionalidade toda! Tudo!”

Mas você, como um ótimo gerente de produto que precisa zelar pela sua imagem e pela imagem do produto não pode colocar no ar uma funcionalidade feita pela metade, não é o mesmo? Ainda mais com os desenvolvedores dando estimativas altas. Ferrou! Você nunca vai ver a sua funcionalidade.

E aí o caos começa, brigas, discussões calorosas e etc. Se você viu isso acontecendo é provavelmente porque o gerente de produto da sua equipe não está com o mindset lean.

Se isso acontecer, você provavelmente tem em mãos um épico. Ou seja, uma grande User Story. Um épico deve ser composto por várias User Stories pequenas para facilitar o desenvolvimento. Vamos entender passo a passo como fazer isso.

Menos é mais!

Pequenas User Stories são melhores que grandes User Stories.

Vantagens

– Através de pequenas iterações você está sempre entregando valor para o usuário. Seja externo ou interno.
– Os desenvolvedores conseguem estimar com mais precisão
– Sua velocidade de entrega não fica variando muito
– A funcionalidade como um todo acaba sendo entregue mais rápido
– Ninguém merece ficar trabalhando na mesma história por uma semana, nem você como cara de produto nem os desenvolvedores.

Exemplo — Como quebrar uma grande user story em várias histórias pequenas

Toda a história deve, por si só, entregar valor para o usuário. Histórias muito detalhadas ou técnicas demais normalmente não entregam valor para o usuário. Esse é um erro que eu já vi se repetir várias vezes. É um erro que eu já cometi e é muito comum. Mas ser comum não deixa de ser um erro terrível.

O exemplo abaixo mostra uma abordagem diferente que ajuda a evitar esse tipo de problema.

Exemplo ruim (toda funcionalidade em uma história)

Eu poderia fazer infinitos “E”. Nesse exemplo nós podemos quebrar em, no mínimo, 6 histórias diferentes.

Bom exemplo (quebrando a funcionalidade em várias histórias)

1) Usuário deleta email
2) Usuário recebe mensagem com confirmação que o e-mail foi deletado
3) Usuário vê contador de emails na lixeira aumentar
4) Usuário vê contador de emails na caixa de entrada diminuir
5) Usuário vê os e-mails deletados quando clica na lixeira
6) O sistema apaga automaticamente os emails que foram deletados há 30 dias

Com essa abordagem, você pode liberar a funcionalidade principal (deletar e-mails) e depois ir iterando o software pra otimizar a experiência do usuário.

NOTA: Como você é um cara bacana, você pode pensar em dividir suas histórias em Front-end e Back-end pra deixar os desenvolvedores mais felizes. NÃO FAÇA ISSO! Lembre-se que a User Story precisa entregar valor para o usuário. Fazer front-end e back-end não entrega valor pra ninguém. Pense comigo, o que o usuário iria dizer se ao clicar no botão "Deletar" o e-mail não fosse deletado?

Cenário feliz vs Cenário ruim

Um cenário feliz é composto pelas ações que o usuário faz pra concluir uma tarefa. Ele faz tudo certinho e sem errar nada. Mas quem dera todo usuário fosse esperto assim! Por isso existe o cenário ruim, que são todas as exceções de caso.

Para resolver isso, em vez de escrever várias histórias que listam todos os casos de uso possíveis, quebre elas em casos específicos.

Exemplo ruim

História: “Como usuário eu devo conseguir fazer login no sistema perfeitamente”
Cenário: Usuário acessa o site quando o login e senha estão corretos
Dado que eu sou um usuário com login e senha corretos
E eu clico em "Entrar"
Então eu devo acessar o meu perfil

Cenário: Usuário não acessa site com login e senha corretos
Dado que eu… (você entendeu o exemplo)

Bom exemplo

Crie histórias individuais pra cada cenário

– Usuário acessa o site com login e senha corretos
– Usuário vê mensagem de erro quando tenta acessar com login incorreto
– Usuário vê mensagem de erro quando ele não confirmou sua conta
– Usuário vê mensagem de erro quando conta não existe

… E assim por diante. Muito mais fácil de entender. Mais rápido de implementar e até mais fácil de escrever!

O que você achou? Concorda? Discorda? Possuí uma técnica mais interessante? Vamos discutir. É só comentar.

Originalmente publicado aqui: https://www.marcell.com.br/como-escrever-boas-user-stories