O documento fornece orientações sobre como escrever histórias de usuário de forma efetiva, discutindo os principais elementos que compõem uma história de usuário, como a declaração de valor e critérios de aceitação, e abordando tópicos como diferenciar histórias de especificações e requisitos, focar no usuário, e identificar o que realmente não constitui uma história de usuário.

1. Histórias de Usuário
Augusto Rückert
Product Manager @ Grupo Zap
The Best The Rare The Rest

2. grupozap.com

3. Era uma vez…
The Best: Histórias de usuário 101
The Rare: Escrevendo histórias melhores
The Rest: Quando não é uma história

4. The Best
História de Usuário 101

5. ?.

6. O que é uma história de usuário?
?. Histórias de usuário 101.

7. 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.
O que não é uma história de usuário...
×

8. Uma história de usuário é...
É uma requisição de funcionalidade sobre o ponto de
vista do usuário
É uma expressão negociável de uma necessidade
É uma expressão de um incremento usável de software

9. Por que escrevemos histórias,
não especificações ou requisitos?
?. Histórias de usuário 101.

10. Facilitam o diálogo
Qualquer um pode escrever
Qualquer um pode entender a demanda
Focam na entrega de valor
Facilitam a mudança de comportamento
Descrevem uma possibilidade/demanda, não uma solução
Escrevemos histórias pois elas

11. Cascata: o objetivo aqui é gerenciar e garantir o escopo e reduzir o risco

12. Cascata: esse documento contém TUDO?!

13. 3Cs
!. Histórias de usuário 101.
Componentes da histórias de Ron Jeffries

14. Cartão
Conversação
Confirmação
!. 3Cs.

15. Sucinta
Compreensível por todos
Descartável
Não é um requisito a ser rastreado
3Cs - Cartão

16. Discutida e negociada
Não é uma ordem
É uma ferramenta para o diálogo e tomada de decisão
3Cs - Conversação

17. Todos confirmam seu entendimento
Há consenso
O valor está claro
Conseguimos progredir
3Cs - Confirmação

19. Declaração de Valor
Critérios de aceitação
Anatomia básica de um Cartão

20. Declaração de Valor
Critérios de aceitação
Anatomia básica de um Cartão

21. Modelos de Declaração de Valor
!. Histórias de usuário 101.

22. Como/Sendo um <papel/persona/perfil>
quero/preciso/necessito de <meta/desejo>
pois/de modo que <benefício>
Modelo Connextra (padrão mais conhecido)

23. Exemplo
Como um Vendedor
quero adicionar novos itens em um pedido recorrente
de modo que não precise reagendar tudo novamente
Modelo Connextra (padrão mais conhecido)

24. Mike Cohn
Como um <papel/persona/perfil>
quero/preciso/necessito de <meta/desejo>
Variações do Modelo Connextra

25. Mike Cohn
Como um Vendedor
quero listar todos os pedidos de um cliente
Variações do Modelo Connextra

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

27. Chris Matts
A fim de visualizar toda minha infraestrutura
como um Administrador de rede,
eu quero uma visão centralizada dos meus elementos
monitorados
Variações do Modelo Connextra

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

29. Variações do Modelo Connextra
5Ws (Who, When, Where, What, Why)
Como Vendedor,
ao acessar as últimas vendas efetuadas,
eu preciso ordená-las por data de entrega,
porque preciso avisar os clientes do prazo dado pela
fábrica

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

31. Variações do Modelo Connextra
Para demonstrar diferenciação
Diferente do relatório de compras atual,
Como administrador,
Eu quero/preciso que seja informado quem efetuou a
compra

32. The Rare
Escrevendo histórias melhores

33. INVEST
!. Escrevendo histórias melhores.

34. Independente (Independent)
Negociável (Negotiable)
Possui valor para os usuários/clientes (Valuable to users)
Estimável (Estimatable)
Pequena (Small)
Testável (Testable)
Seis atributos para uma boa história, de Bill Wake

35. Não seja genérico
!. Escrevendo histórias melhores.

36. Não use declarações vagas: "Como usuário..."
Uma das grandes vantagens das histórias dos usuários é fazer com que os
desenvolvedores entendam mais das motivações dos usuários e tenham
maior empatia por eles.
Identifique quem é o usuário

37. A identificação do usuário deve servir como ponto para
discussão:
O que ele faria?
Como ele faria?
Qual abordagem se adapta melhor a esse usuário?
Identifique quem é o usuário

38. Defina quando e onde:
"[...] a listagem de contatos [...]"
"[...] quando adiciono um novo pedido de frete [...]"
"[...] ao finalizar a inclusão de um novo host na
monitoração [...]"
Identifique o contexto

39. Defina um contexto maior: um objetivo de negócio que
sustente mais de uma história
Um contexto genérico não irá prover nada de interessante para discussão e
melhoria do produto. Somente será uma desculpa para o aumento
descontrolado do escopo, baseado em vontades individuais ou opiniões de
Hippos
Identifique o contexto

41. Avalie a zona de controle
e a esfera de influência
!. Escrevendo histórias melhores.

42. Todo sistema tem 3 áreas:
A zona de controle que inclui aquelas coisas no sistema
que nós podemos mudar nós mesmos
Um pouco de teoria de sistemas...

43. Todo sistema tem 3 áreas:
A zona de controle que inclui aquelas coisas no sistema
que nós podemos mudar nós mesmos
A esfera de influência que inclui atividades que nós
podemos impactar, mas não exercemos controle sobre
Um pouco de teoria de sistemas...

44. Todo sistema tem 3 áreas:
A zona de controle que inclui aquelas coisas no sistema
que nós podemos mudar nós mesmos
A esfera de influência que inclui atividades que nós
podemos impactar, mas não exercemos controle sobre
E o ambiente externo que inclui os elementos que não
temos nenhuma influência
Um pouco de teoria de sistemas...

45. O motivo da necessidade do usuário
deve estar na esfera de influência do time
O entregável (o que o usuário quer)
deve estar na zona de controle do time
Em uma boa história...

46. Como gerente de vendas, eu preciso saber o número total de
vendas por vendedor, pois assim posso calcular e submeter
as comissões mensais para o RH da empresa

47. Como gerente de vendas, eu preciso saber o número total de
vendas por vendedor, pois assim posso calcular e submeter
as comissões mensais para o RH da empresa
Zona de controle do time
Esfera de influência do time

48. Uma boa história implica
em ter algum risco
!. Escrevendo histórias melhores.

49. Micro-histórias
Histórias enganadoras
Histórias falsas
Situações nas quais não há riscos...

50. Micro-histórias
Difícil identificar os riscos
Não são problemáticas por si só
Devem ser eliminadas em planejamentos de médio e longo
prazo
Situações nas quais não há riscos...

51. Jeff Patton nos diz para pensar em Asteroids…

52. Histórias enganadoras
Descrevem uma solução, e não uma necessidade do usuário
Situações nas quais não há riscos...

53. Histórias enganadoras
Como administrador do sistema, quero poder acessar mais
rapidamente a interface principal, por isso preciso que a carga
de requisições da interface seja reduzida/saneada
Situações nas quais não há riscos...

54. The Rest
Quando não é uma história

55. Não escreva histórias falsas
!. Quando não é uma história.

56. Como desenvolvedor, eu preciso
eliminar as tabelas duplicadas da base
de dados
?. Quando não é uma história.

57. Como P.O., eu quero que na listagem de
endereços a coluna de nomes fique mais
destacada que a coluna de valores
?. Quando não é uma história.

58. Como testador, eu preciso preparar o
plano de testes da versão 3.5
?. Quando não é uma história.

59. Por que esses enunciados não são
histórias de usuário?
?. Quando não é uma história.

60. Histórias falsas são aquelas que
enunciam necessidades do time:
Como desenvolvedor, eu preciso…
Como P.O., eu quero…
Como testador, eu preciso...
Não são usuários... tanto a necessidade quanto a entrega estão na zona de
controle do time
Por que não é uma história?

61. Não se trata de um usuário
Não é uma requisição de uso para uma persona
Não traz valor para o negócio
Por que não é uma história?

62. Se não traz valor para o usuário,
por que fazemos?
?. Quando não é uma história.

63. Bem mais fácil gerar funcionalidades desnecessárias quando fazemos o que queremos

64. Quando é algo que precisamos fazer
!. Quando não é uma história.

65. Preparação/Manutenção de ambiente
Correções de defeitos
Ajustes pontuais e melhoria de performance
Não entrega valor, mas precisa ser feito

66. Saber expressar o que precisamos discutir e fazer

67. Faça para não precisar fazer mais
Descreva a ação a ser tomada
Discuta e escreva
Foque no que pode ser automatizado
Para preparar/ajustar o ambiente

68. Decreva o que está errado
Descreva o comportamento aberrante
Descreva o comportamento esperado
Demonstre ação ou condição
Ao executar [...]
Quando [...]
Para correções de defeitos

69. Descreva a necessidade
O que precisa ser feito, não como faremos
Tenha ciência de que você (geralmente) já está em dívida
Escreva de forma a manter a conversação
Demonstre o valor de fazer aquilo
Para ajustes pontuais e melhoria de performance

70. Descreva a necessidade
Precisamos <necessidade>,
pois <motivo>
Para ajustes pontuais e melhoria de performance

71. Descreva a necessidade
Precisamos ajustar o tamanho das colunas,
pois algumas estão com o texto do cabeçalho cortado
Para ajustes pontuais e melhoria de performance

72. Quando é uma pergunta
!. Quando não é uma história.

73. Quando é uma pergunta
Há algo a ser feito, mas não sabemos como
!. Quando não é uma história.

74. Se quem fez a requisição não sabe o que quer, vamos descobrir juntos

75. Há algo a ser feito, mas não sabemos como:
Testar uma tecnologia
Há alto grau de incerteza na aplicação
Não é possível estimar
Falta conhecimento no time
Temos dúvidas sobre isso...

76. Determine qual a pergunta a ser respondida
Determine qual a entrega esperada
Determine um tempo razoável a ser consumido para
ter a resposta
Negocie quais aspectos serão levados em conta e
quais não
A sua requisição é uma pergunta

77. Antes de ir embora...

78. Antes de ir embora...

79. Escreva cedo a declaração de valor e deixe para
detalhar depois
Evite escrever soluções
Pense em mais de um stakeholder que pode tirar
proveito da solução para a situação elencada. Isso
abre oportunidade para quebrar a história depois
Dicas finais

80. Use figuras para explicar a história
Escreva as dúvidas
Foque na declaração do problema/necessidade do
usuário ao invés do problema técnico
Discuta a história
Dicas finais

81. Fifty Quick Ideas to Improve Your User Stories
Gojko Adzic, David Evans
User Stories Applied
Mike Cohn
User Story Mapping
Jeff Patton
Algumas referências

82. Alguma pergunta?
Obrigado :)
Augusto Rückert
Product Manager @ Grupo Zap
@ruckert
augusto.ruckert@grupozap.com