Dicas para escrever boas histórias no contexto do desenvolvimento ágil de software.

1. USER
STORIES

2. USER STORIES
 Histórias precisam ser escritas de uma forma que
todo o time entenda (negócio, analistas,
desenvolvedores, testers)
 A escrita de uma história deve envolver
diferentes papeis
 Colocar em produção deve ser uma decisão de
negócio

3. UMA BOA HISTÓRIA É:
 Independente
 Negociável
 Valiosa
 Estimável
 Small (pequena)
 Testável
 I
 N
 V
 E
 S
 T

4. INDEPENDENTE
 É muito mais fácil trabalhar com histórias
quando elas são independentes
 A ideia é sermos capazes de programar e
implementar em qualquer ordem
 Colocar em produção deve ser uma decisão de
negócio

5. NEGOCIÁVEL
 Uma boa história é negociável
 Não é um contrato explícito de features. Os
detalhes são criados pelo cliente e programadores
durante o desenvolvimento
 Uma boa história captura a essência, não os
detalhes
 O card pode conter notas, ideias de teste, tudo o
que puder ajudar na comunicação

6. VALIOSA
 Uma história precisa ter valor para o cliente
 O valor deve ser levado em conta na hora de
quebrar uma história
 As histórias devem ser tratadas como pedaços de
bolo

7. ESTIMÁVEL
 Uma boa história pode ser estimada
 Não precisa ser algo preciso, mas apenas o
suficiente para o cliente ordenar e programar a
implementação das histórias
 Histórias muito grandes são confusas e difíceis de
estimar

8. PEQUENA
 Boas histórias tendem a ser pequenas
 Histórias pequenas são fáceis de entender, de estimar
e executar
 É mais fácil controlar e alterar o escopo com valor se
você tem histórias pequenas
 Mas histórias muito pequenas podem gerar
dependência e/ou bloqueio. Cuidado com a ordenação
na priorização
 O maior propósito de dividir coisas em histórias
pequenas é conseguir feedback rápido

9. TESTÁVEL
 Uma boa história é testável
 Testar as features antes da implementação deixa
o time mais produtivo
 Os testes ajudam a descobrir se o objetivo foi
atingido
 O time pode tratar requisitos não-funcionais
(performance e usabilidade) como coisas que
também precisam ser testadas. Descobrir como
operacionalizar esses testes pode ajudar o time a
aprender sobre necessidades verdadeiras

10. A ORDEM ESTÁ CORRETA?
 Independente
 Negociável
 Valiosa
 Estimável
 Small (pequena)
 Testável
 Valiosa
 Testável
 Small (pequena)
 Independente
 Negociável
 Estimável

11. ELEMENTOS DE UMA HISTÓRIA
 O título da história nos ajuda a determinar o
“done”
 Narrativa: a função é mostrar o benefício da
feature
 Os títulos dos cenários devem dizer o que é
diferente
 Dado que [algum contexto]
Quando [eu faço alguma coisa]
Então [Essa nova coisa acontece]

12. REFERÊNCIAS
 BDD in the large
http://lizkeogh.com/2012/06/01/bdd-in-the-large/
 Your stories are too big
http://goodrequirements.com/2012/too-big/
 What’s in a Story?
http://dannorth.net/whats-in-a-story/
 INVEST in Good Stories, and SMART Tasks
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

13. Bruna Gomes
brugome@gmail.com
Skype: brugome