1. WORKSHOP
USER STORIES
Para promover times autônomos
Mayra Souza e Eluza Pinheiro

2. Eu sou Mayra Souza!
Agile Coach no Grupo Zap Viva Real empresa do
Grupo Globo. Facilitadora e idealizadora da
iniciativa AÇÃO.
É Engenheira de Produção (PUCRS), Professional &
Self Coaching (IBC) tem especializações de Scrum
Product Owner, FMEA de processos, Auditoria,
Management 3.0 e Visual Thinking. Atuou 2 anos na
ThoughtWorks junto com Paulo Caroli em
facilitações de Lean Inception e apoiou no
desenvolvimento de novas pessoas facilitadoras.
Exerceu os papéis de analista de negócios, coach e
facilitadora de práticas ágeis
2

3. Olá, sou a Eluza!
Atualmente, sou Product Manager no
Grupo Zap Viva Real, mas me criei
designer. Pesquiso sobre UX, como
aprender e também novos jeitos de
trabalhar com coisas velhas. Já fui
diretora de arte, webdesigner,
professora, analista de produtos e
negócios. Falo muito sobre os
benefícios de adotar gatos e chás.
3

4. User story = história do usuário
4
O que é User Story?

5. Origem das User Stories
Originou-se com a Extreme Programming (XP), em que os clientes
fazem definição do escopo do produto com as User Stories.
5

6. “Um dos princípios por trás das User
Stories é a de que o produto poderia
ser integralmente representado por
meio das necessidades de seus
usuários
(Jeffries et al., 2000). 6

7. 7
Por que escrevemos histórias,
não especificações ou requisitos?

8. 8
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Lembrando o que o manifesto ágil diz:

9. Três C’s, para verificar a qualidade de uma US:
- Cartão é um símbolo físico dando forma tangível e durável. A
ideia do cartão é garantir que a descrição da US seja sucinta,
objetiva, direta.
- Conversa, a demanda deve ser discutida e negociada. A história
não é uma ordem, mas uma ferramenta para o diálogo e tomada
de decisão;
- Confirmação, a demanda deve ser compreendida por todos. O
valor a ser entregue deve estar claro para os envolvidos.
9
Ron Jeffries
propôs a fórmula
em 2001.

10. User Story
- Proporciona o entendimento comum de ambos os lados (negócio
e técnico)
- Uma técnica de análise de requisitos para o desenvolvimento
iterativo empático
- Propicia o desenvolvimento com a visão do usuário em cada
funcionalidade
- É uma fatia do escopo do produto a ser desenvolvido
10

11. Dinâmica 1
- Dividam-se em pares
- Escolham um caso
- Escreva a história para o caso escolhido
Caso 1: O cliente do sistema, na review de entrega do MVP 2,
sugeriu que fosse implementado usuário administrador no sistema
Caso 2: O cliente do sistema, na review de entrega do MVP 2,
sugeriu que fosse implementado um formulário para o envio de
sugestões e requisições
11

12. Conhece o INVEST?
Ele ajuda avaliar boas características de uma US com qualidade:
Independente – de todos o outros
Negociável – elaborado colaborativamente durante o
desenvolvimento, não é um contrato
Valiosa/ vertical – entrega de valor para o negócio/ usuário
Estimável – para uma boa aproximação
Sucinta/ pequena – simples e encaixa dentro de uma iteração
Testável – possível determinar quando está pronta
12
Bill Wake
elaborou o acrônimo.

13. Pergunte nesta ordem
- Valiosa/ vertical
- Testável
- Sucinta/ pequena
- Independente
- Negociável
- Estimável
13

14. Dinâmica 2
- Dividam-se em pares
- Peguem as USs da Dinâmica 1
- Avaliem se estão com as características INVEST:
- Valiosa/ vertical
- Testável
- Sucinta/ pequena
- Independente
- Negociável
- Estimável
- Reescrevam a US para que atendam no mínimo as 3 primeiras
características 14

15. User story = história do usuário
15
Tipos de User Stories

16. Tipos de USs
Não existe um jeito certo de escrever uma US, mas convencionou-se
algumas maneiras de escrever que ajudam a ter todas as
características do INVEST. Essas USs são narrativas (pois tratam da
empatia com o usuário) ou são declarações de valores (pois pensam
no negócio como um todo).
16

17. Modelo Connextra
Como/Sendo um <papel/persona/perfil>
quero/preciso/necessito de <meta/desejo>
pois/de modo que <benefício>
17

18. Variações do modelo Connextra
Como um <papel/persona/perfil>
quero/preciso/necessito de <meta/desejo>
(Mike Cohn)
18

19. Variações do modelo Connextra
A fim de <benefício a ser recebido>
como um <papel/persona/perfil>,
eu quero <meta/desejo>
(Chris Matts)
19

20. Variações do modelo Connextra
Como <quem>,
<quando> <onde>,
eu <o que>,
porque <por que>
[5Ws (Who, When, Where, What, Why)]
20

21. Variações do modelo Connextra
Diferente do(a) <situação atual ou indesejada>,
Como <papel>,
Eu quero/preciso que <situação desejada>
[Para demonstrar diferenciação]
21

22. Job Story
Quando (situação)
Quero (motivação)
Então poderei (resultado esperado)
(Alan Klement)
22

23. Fatiando o produto em US e tarefas
Para tarefas resultantes da
decomposição técnica de US,
elaborou o acrônimo
SMART (específico,
mensurável, alcançável,
relevante, time-box)
23

24. É uma descrição utilizando uma narrativa:
Como um [papel/ usuário]
Eu quero [objetivo]
Para então [valor/ benefício]
Captura o "quem", "o quê" e "por quê" de um requisito/ funcionalidade.
User Stories
24

25. Critérios de aceitação (CA)
- Captura o comportamento esperado
- Confirma quando a US está pronta
- Permite que a estória seja “testável”
- US pode ter quantos CA necessários
- Declaração de QUANDO deve ser possível de automatizar
- Devemos utilizar verbos fortes na escrita dos cenários
Dado que [contexto]
Quando [evento]
Então [resultado]
25

26. O que pode conter uma User Story?
- Narrativa: Como um [papel/ usuário] Eu quero
[objetivo] Para então [valor]
- Critérios de aceitação: Dado que [contexto] Quando [evento] Então
[resultado]
- Contexto
- Escopo (dentro e fora do escopo)
- Tarefas
- Fluxos e diagramas
- Protótipo e desenho de interface do usuário
26
Sem Burocracia

27. Dinâmica 3
- Dividam-se em pares
- Pegue a US da Dinâmica 2
- Inclua as informações necessárias para sua US:
◈ Critérios de aceitação: Dado que [contexto] Quando
[evento] Então [resultado]
◈ Contexto
◈ Escopo (dentro e fora do escopo)
◈ Tarefas
◈ Fluxos e diagramas
◈ Protótipo e desenho de interface do usuário
27

28. Lembre-se
- US não está escrita em PEDRA
- A cada interação pode ser retirado ou incluído algo que é
necessário
- A US define a experiência de desenvolvimento (facilitar ou
complicar?)
28

29. O que NÃO é uma US...
- Não é uma especificação funcional
- Não é para relatar um bug
- Não é um documento de definições técnicas
- Não é uma enunciação detalhada
- Não é um requisito
- Não é um contrato
- Não é algo para funcionar sem o P.O.
29

30. QA ReviewA qualidade é responsabilidade de todos membros do Time
30

31. 31
Objetivo QA Review
- Atender 2 C’s - Conversa e Confirmação
- Verificação das expectativas de comportamento e dos critérios
de aceite
- Alinhar e entender a US antes do desenvolvimento e após do
desenvolvimento
- Checklist de requisitos a serem cobertos, inclusive os não
funcionais
- Trabalhar de forma puxada (planning está no fluxo de trabalho)
- Melhoria contínua da US

32. Kick-off
Momento antes do
desenvolvimento para alinhar o
que tem de ser desenvolvido
entre pares e PO/ PM ou BA.
Evitando a falta de entendimento
e pode ocorrer novos
questionamento de cenários que
não foram pensados.
O que é QA review?
Desk-check
Momento após o
desenvolvimento em que entrega
para mostrar o que foi feito para
outra pessoa para revisar e testar
o código, com intuito de reduzir
problemas em produção e
refatoração.
32

33. Momentos Kick-off e Desk-check
33

34. Processo
Escrita da US
pareada negócio e
técnico
Kick-off
desenvolvimento
e quem escreveu
a US
Codar
34
Desk-check
desenvolvimento
com quem vai
revisar e testar

35. Kick-off - entre 5 e 10 min.
- As pessoas desenvolvedoras leem a US que querem desenvolver,
chamam para Kick-off quem participou da escrita da US e que
tem contexto
“Passagem de bastão” dos papés PO/ PMs ou BAs para
desenvolvedores e analistas de qualidade
- Quanto mais cedo for realizado, maior será a flexibilidade para
mudanças e menor será o risco de um maior custo no
desenvolvimento
35

36. Kick-off - entre 5 e 10 min.
- Validar mais uma vez a cobertura dos cenários a serem testados
posteriormente
- Identificar possíveis conflitos da US em questão com alguma
outra feature já existente
- Verificar dependências
- Revisão de critérios ambíguos ou cenários que estejam faltando
- Promover o entendimento das novas features que a história
implementará e os cenários a serem cobertos
- A indisponibilidade do PO/PM, BA ou QA não deve atrasar o
desenvolvimento da história
36

37. Desk-check - entre 10 e 15 min.
- Depende do seu fluxo de trabalho, neste caso conforme o slide
com kanban é antes de ir para fase de QA
- É uma conversa tipo uma mini-review do que foi desenvolvido
- As pessoas que desenvolveram passam o bastão para as pessoas
que irão revisar e testar, com intuito de fazer um double check
das features desenvolvidas:
- A nova feature faz o que era esperado?
- A nova feature introduziu algum comportamento
inesperado?
- Os testes estão ok após o desenvolvimento da nova
feature? 37

38. Desk-check - entre 10 e 15 min.
- Visualiza-se as novas features em ambiente de desenvolvimento
(pois se encontrado algum problema, não há necessidade de se
fazer roll back)
- Faz primeiro a leitura da US, passando por cada critério de
aceitação e valida em alto nível o que foi desenvolvido
- Neste momento, encontrar bugs e problemas é muito melhor e
mais barato que encontrar após a fase de desenvolvimento, o
problema será identificado com mais facilidade.
38

39. Dinâmica 4
- Voltem nos pares da Dinâmica 3
- Troquem as USs reescritas na Dinâmica 3 com outra dupla que
tenha uma caso diferente do seu
- Cada dupla leia a US da outra dupla e conversem qual foi a
interpretação. Analisar se a dupla tem a mesma visão ou se
interpretam diferente
- Após façam kick-off com as duplas que escreveram a US que vocês
estavam analisando, e vejam o que realmente a dupla quis informar ao
escrever a US
39

40. 40
Agradecemos sua
participação!
Dúvidas, sugestões e feedback:
mayra.souza@zapcorp.com.br
https://br.linkedin.com/in/mayrarodriguesdesouza
@paola_mayra
eluzapinheiro@gmail.com
https://www.linkedin.com/in/eluzapinheiro/
@usinadeux

41. REFERÊNCIAS
INVEST in Good Stories, and SMART Tasks – Bill Wake
K21 - O que é a User Story?
Agile Alliance - Invest
Scrum gestão ágil para projetos de sucesso – Rafael Sabbah
Como fatiar seu produto em estórias que façam sentido – Luis
Mizutani e Mayra Souza
Histórias de usuários - Declaração de valor -
Augusto Rückert
41

42. SlidesCarnival icons are editable
shapes.
This means that you can:
● Resize them without losing
quality.
● Change fill color and opacity.
Isn’t that nice? :)
Examples:
42

43. Now you can use any emoji as an icon!
And of course it resizes without losing quality and you can change
the color.
How? Follow Google instructions
https://twitter.com/googledocs/status/730087240156643328
✋ ❤
and many more...
43