O documento discute user stories no contexto de SCRUM e XP. Explica que user stories são descrições sucintas de funcionalidades do sistema escritas pelos clientes para definir requisitos preliminares. Detalha os aspectos críticos de user stories, como cards, conversation e confirmation, e o framework INVEST para criar boas user stories. Apresenta também exemplos e exercícios para aplicar o modelo de criação de user stories.

1. User StoriesUser Stories
Por: Ricardo MouraPor: Ricardo Moura

2. User StoriesUser Stories
Clássico Product Backlog
No SCRUM, de acordo com Schwaber e Beedle
(2002), os requisitos conhecidos até o momento
são listados, dando origem ao Product Backlog.
Estes requisitos são agrupados de acordo com
suas prioridades, apresentando as seguintes
informações: descrição do requisito; tempo
estimado para o desenvolvimento; responsável
pelo desenvolvimento.
No XP, a definição preliminar dos requisitos é
feita a partir das escritas das User Stories pelos
clientes. As User Stories são descrições textuais
sucintas a respeito das funcionalidades do
sistema (BECK, 2000).

3. Story
• Funcionalidade no mundo do software, estória no mundo
XP/SCRUM;
• O termo em inglês é story (estória – conto) e não history (história –
relato de fatos);
• Estórias são equivalentes a requisitos;
• Um produto de software é um conjunto de estórias;
É basicamente uma lista de requisitos, funções que o donoÉ basicamente uma lista de requisitos, funções que o dono
do negócio solicita e que espera que elas sejam entregues,do negócio solicita e que espera que elas sejam entregues,
descrita em linguagem coloquial.descrita em linguagem coloquial.
User StoriesUser Stories

4. Aspectos Críticos: 3C
As estórias possuem três aspectos críticos, os quais devem ser "obrigatoriamente"
lembrados ao serem criadas:
Cards - Estórias devem ser escritas em cartões ou post-its
para obrigá-las a serem pequenas;
Conversation - Lembrete para identificar uma funcionalidade
que foi conversada e discutida com os stakholders;
Confirmation - O cliente define (implícita ou explicitamente)
uma maneira de validar esse pedido.
User StoriesUser Stories

5. Exemplos da utilização do 3C
Cards
"Um administrador pode cadastrar um jogo para que os apostadores possam fazer
seus palpites de resultado"
Conversation
O administrador pode cadastrar o jogo quando quiser? E se ele cadastrar muito em
cima?
- Ah, eu acho que ele tem que cadastrar com no mínimo 48h de antecedência
- Legal... concordo
Confirmation
• Um administrador não poderá cadastrar um jogo com menos de 48h de
antecedência
• O jogo deve pertencer ao campeonato corrente
• Um administrador não poderá cadastrar dois jogos envolvendo os mesmos times
no mesmo horário
User StoriesUser Stories

6. INVEST
Independent : Estórias devem ser independentes uma das outras;
Negotiable : Estórias não são contratos, mas lembretes para discussões;
Valuable : Estórias devem agregar valor para o cliente;
Estimatable : Os desenvolvedores devem ser capazes de estimar o
tamanhos das estórias;
Small : estórias grandes dificultam as estimativas. Bem como estórias
muito pequenas. Quebre ou agrupe dependendo do caso.
Testable : Estórias devem ser possíveis de serem testadas.
User StoriesUser Stories

7. Exercício 1
Imagine que você é um construtor de móveis e alguém lhe
apresenta o problema exposto na figura abaixo como
necessidade para criação de um novo produto.
Escrevas estórias baseadas no que foi
apresentado até o momento.
User StoriesUser Stories
Escrevas estórias baseadas no que foi
apresentado até o momento.

8. Como um <PERFIL> eu posso/gostaria/devo
<FUNÇÃO> para <VALOR AO NEGÓCIO>
Modelo de descrição
User StoriesUser Stories
Como um <TOMADOR DE SERVIÇO> eu gostaria de
<IMPRIMIR A NOTA FISCAL > para <COMPROVAR O
SERVIÇO PRESTADO>

9. A resposta à esta pergunta é representada pelo <PERFIL>. Analisando de
uma outra forma, podemos dizer que representa o “papel” exercido pelo
usuário no fluxo do negócio.
Pergunta: Quem deseja imprimir a nota fiscal?
Resposta: Tomador de Serviço
Modelo de descrição : Quem?
User StoriesUser Stories

10. Respondendo a esta pergunta encontraremos uma das partes mais
importantes da estória, que representa o real desejo do dono do negócio: a
<FUNÇÃO>. Também para os desenvolvedores, essa é a informação mais
valiosa, pois vai determinar o que deve ser feito.
Pergunta: Após a nota fiscal ter sido emitida, o que deseja realizar?
Resposta: Imprimir a nota fiscal.
Modelo de descrição : O QUE?
User StoriesUser Stories

11. SCRUMSCRUM
Pode não parecer, mas esta é uma das perguntas mais difíceis de ser
respondida. Isso porque na maioria das vezes o motivo não é visto como
algo muito importante tornando-se uma tarefa árdua mensurar o <VALOR
AO NEGÓCIO>.
Pergunta: Por que precisa imprimr a nota fiscal?
Resposta: Para comprovar o serviço prestado.
Modelo de descrição : POR QUE?

12. •Como um <Cliente> eu posso <pesquisar produtos> para <agilizar as
minhas compras>;
•Como um <gerente comercial> eu devo <dar opções de pagamento> para
<facilitar a compra dos meus clientes>;
•como um <gerente de contas> eu devo <oferecer planos de vendas> para
<fidelizar meus clientes>;
•Como um <Cliente de Negócios> eu posso <pesquisar recurso de
divulgação de produto> para <aumentar as minhas vendas>;
Exemplos com o modelo de descrição
User StoriesUser Stories

13. Exercício 2
Reescreva as estórias que criou no Exercicío 1,
aplicando o modelo proposto.
User StoriesUser Stories

14. Index Card Informal
User StoriesUser Stories

15. Index Card Formal: Frente
User StoriesUser Stories

16. Index Card Formal: Verso
User StoriesUser Stories

17. Modelo de User Storie proposto pela MCP
Index Card no Centro de Conhecimento
User StoriesUser Stories

18. “A história deve ser compreensível para clientes e
desenvolvedores, testável, valiosa para o cliente, e
suficientemente pequena para que os programadores possam
criar meia dúzia em uma iteração.”
Retirado do livro Planning Extreme Programming de Kent Beck e Martin Fowler
Resumindo ...
User StoriesUser Stories

19. Perguntas ???
User StoriesUser Stories

20. Obrigado!
User StoriesUser Stories