Como escrever histórias de usuário — templates e técnicas

Quer sabe como escrever histórias de usuário? Vem comigo…

Uma coisa é redigir as entregas em formato de histórias de usuário (User Story), outra coisa é redigir boas histórias de usuários. Para isso, antes de te falar como criar boas histórias de usuário vou te explicar o que é uma história de usuário, porque elas foram criadas e para que . Ao final deste conteúdo, você terá um GUIA PRÁTICO para criar boas histórias de usuário. Vamos lá?

Por que o formato USER STORY foi criado

Quem trabalha com pessoas de TI sabe como é complicada a comunicação com estes seres. Geralmente, quem é de TI, fala que o cliente não sabe pedir, e o cliente, fala que o pessoal da TI não consegue entender nada.

O resultado são entregas totalmente desalinhadas com a expectativa do cliente.

Para atender devidamente a expectativa do cliente, um erro que não pode acontecer é a dupla interpretação sobre qualquer coisa que é solicitada.

Esse entendimento dúbio se dá na hora da comunicação.

Comunicação sempre foi um problema gravíssimo no desenvolvimento de software.

Problema esse, que o Gerenciamento Tradicional de Projetos de Software tentou resolver com documentações extensas e que ninguém lia. Aquela bíbilia de requisitos!

Resultado? Desperdício puro! Uma vez que investiamos horas e horas para redigir documentos de requisitos que nunca foram lidos por nenhum programador na terra.

Para resolver esta questão de requisitos e poder iniciar um papo com a equipe sobre o que deve ser construido, o formato de História de Usuário foi sugerido, utilizado e amplamente difundido no desenvolvimento de software.

Afinal , em pouco mais de 2 linhas já conseguimos conceituar o problema que iremos atacar de forma a eliminar ao máximo as ambiguidades.

Este é o porquê da criação destes pequenos fragmentos de texto pré formatados, para especificar um contexto de atuação: Clareza, simplicidade e propósito. O que chamo de “Documentação de Requisito enxuta”.

Quem criou o formato de user story (histórias de usuário)

Essa pergunta é capciosa e quando vamos tentar puxar este fio vem um monte de gente. Fato é que essa temática ronda no mundo do XP e abaixo eu tento dar as honras aos caras que mencionaram, esgotaram e popularizaram o termo.

Tudo indica que o formato de User Story surgiu com a galera de XP (Extreming Programming). Sendo referenciada por Kent Beck, Ron Jeffries e Ward Cunningham ao longo do tempo em suas publicações.

1998

Alistair Cockburn, mencionou este nome (USER STORY) em uma visita à Chrysler em um projeto que participava. Alistair é um dos signatários do Manifesto Ágil para desenvolvimento de software.

User story é uma promessa para a conversa. — Alistair Cockburn

1999

Kent Beck publica a primeira edição do livro Extreme Programming Explained. Fazendo referências ao uso do formato de História de Usuário no “Planning Game”.

2001

No ano do Manifesto Ágil para desenvolvimento de software, Ron Jeffries propõe o formato dos 3 C’s para a elaboração de uma User Story.

CARTÃO > CONVERSA > CONFIRMAÇÃO

2004

Mike Cohn extrapola a aplicação de Histórias de Usuário, indo muito além dos cartões. As aplicações para o formato são publicadas em seu livro Histórias de Usuário Aplicada para desenvolvimento Ágil de Software. Hoje, considerado referência no assunto por Martin Fowler.
Por sua vez, Mike nomeia Rachel Davies como “inventor” das histórias de usuários.

2014

Neste ano , Jeff Patton publicou a técnica de mapeamento de User Story em seu livro User Story Mapping: Discover the Whole Story, Build the Right Product.

O que é uma história de usuário?

Uma história de usuário é a definição textual das necessidades de uma pessoa. Em geral, ela segue uma estrutura pré estabelecida onde busca em 3 linhas contextualizar o problema a ser atacado.

No desenvolvimento de software, ela é usada para contextualizar uma equipe de desenvolvimento sobre o que deverá ser codificado.

Hoje em dia, com a agilidade transcendendo a TI, o formato de História de Usuário pode e deve ser utilizado sempre que formos iniciar um papo sobre quem vai usar nosso produto ou serviço.

A seguir, darei um exemplo muito comum na definição de demandas para um grupo de desenvolvedores de TI (onde este formato é mais amplamente difundido).

Template de uma história de usuário

O exemplo mais comum de uma história de usuário segue o formato abaixo:

Eu como <ator>
Quero um/uma <necessidade>
Para que <problema a ser resolvido>

Exemplo de uma história de usuário

Eu como agente de precificação
quero consultar os preços do concorrente
para que eu possa comparar os valores que pretendo praticar em minha loja sem ter de visitar a loja de cada um deles.

Exemplo de uma história de usuário mais detalhada

Eu como <ator>
Quando <gatilho acionador da necessidade>
Quero um/uma <necessidade>
Para que <problema a ser resolvido>

Parece trivial , mas não é. Como um fragmento de texto de 4 linhas vai ser o suficiente para desenvolver algo tão complexo como um incremento de um software?

Não, não é o suficiente e ainda assim encontramos inúmeras disfunções na hora de utilizar esta técnica para redigir sobre um incremento de um produto ou serviço.

Principais erros ao escrever Histórias de Usuário

História de especialistas (HisTera) — Pare de vez de escrever “Eu como front end”. Não coloque uma especialidade de um membro de sua equipe como <ator> da história, a não ser que você esteja desenvolvendo uma ferramenta como uma IDE que vá auxiliar os front-end do mundo. Não existe esse lance de histórias separadas por especialidades. História é de usuário, justamente para fomentar a criação de incrementos de valor e estimular a co-criação.

Histórias para boi dormir (zzz)- Uma história de usuário é um convite para o bate-papo, como Alistair Cockburn mesmo disse. Sabendo disso, não escreva histórias longas. Você terá a oportunidade de complementar as informações nos critérios de aceite dela. User Story não é a descrição sumária da demanda a ser executada. Ela está mais para a introdução, sacou?

Histórias tarefa (historefa) — Tudo bem que no jogo da agilidade temos de quebrar as demandas obscuras em fatias menores de trabalho, mas confundir tarefa com história é outro negócio. Pare de escrever uma tarefa em formato de User Story. Uma história, geralmente, possui várias tarefas atreladas a ela. Tarefas essas, que exigem multidisciplinas para serem tocadas.

Histórias Épicamente Monolíticas (HisTORA) — O nome é complicado né? A história feita neste formato também é. Estas histórias geralmente são incrementos disfarçados. Lobo em pele de cordeiro. O P.O monta algo que se parece uma História de Usuário, mas ali dentro tem um monstro do tamanho do KING KONG. O formato dela parece correto, ela é sucinta, mas a execução dela tráz várias outras histórias à reboque, ferindo o conceito básico de independência.

"Uma LINHA história de amor "— e quando uma demanda, que não necessáriamente é um incremento , vem em uma singela linha? Trocar o texto em um header da página vira uma user story no sprint backlog. Para completar a estimativa do incremento vai lá no alto. Aí é foda!

Como criar boas Histórias de Usuário — INVEST

Agora, como prometi, para ajudar seu time a montar Histórias de Usuário que fazem sentido, te apresento o acrônimo INVEST. Vamos a explicação:

A união das iniciais de cada aspecto de uma boa user story formam a palavra INVEST. Vamos o que torna uma User Story boa?

Independente

Um incremento de qualquer tipo deve ser idependente, uma vez que estamos buscando o desenvolvimento incremental e ágil.

Negociável

A história de usuário deve ser passível de negociação, para que o time tenha sempre a opção de atuar em fatias menores do que se está pedindo e opinar nas mesmas.

Valiosa

Evite a fábrica de entregas. Muitos P.O’s confundem o conceito de entregar serviços e produtos com o maior valor possível, com ocupar ao máximo a equipe com tarefas. Foque no valor daquela fatia (user story) e não na fábrica de entregas.

Recomendo ler o artigo onde abordo a fábrica de entregas:
– O scrum vai para o buraco sem gerenciamento de produto

Estimável

Se não conseguimos estimar o incremento que estamos falando é sinal que ainda temos pouco conhecimento sobre o que deve ser feito. Considere cortar em uma entrega menor e de conhecimento da equipe. Por isso, tudo deve ser negociável.

Small (Pequena)

Complementando o que escrevi acima, o ideal é sempre entregar pequenas coisas com alto valor. Então, ser pequena é uma característica básica de uma User Story. Busque constantemente isso!

Testável

Na hora de validarmos o que produzimos, aquilo tem de ser passível de testes. Afinal, é testando que o cliente vai atestar que o que ele pediu foi feito. Aqui, é fundamental que os critérios de aceite estejam escritos de forma a complementar a User Story.

Conclusão

Parece que não, mas uma simples técnica como esta, vinda do XP (Extremming Programming), dá pano para a manga e gera bastante debate. Principalmente entre SCRUM MASTER ou AGILE COACHES que estejam começando seus trabalhos com equipes novas no ÁGIL. Usar “técnicas” como o INVEST para auxiliar os P.O’s a redigirem boas histórias é o “feijão com arroz” que deveria ser seguido e não é.

E você, conhece outras técnicas? Como andam as definições de incremento em seu time ágil? Que técnicas você tem usado para elaborar suas Histórias de Usuário?

p.s: Em tempos de Chat GPT, pesquisando ainda mais sobre quem criou este formato, aparece o nome da Carolyn Snyder e a menção ao livro Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces (Interactive Technologies) 1st Edition.