O documento explica a diferença entre épicos e histórias de usuário, sendo que épicos são funcionalidades não detalhadas definidas em nível estratégico e histórias de usuário especificam os requisitos funcionais e critérios de negócios dos épicos. Histórias de usuário possuem menor duração, geralmente de uma semana, enquanto épicos podem durar de 1 a 3 meses.

1. Épicos vs. Histórias

2. Antes de tudo: épicos vs. user stories
Em geral, épicos são um conjunto de histórias não
refinadas definidos em nível estratégico de uma empresa.
Sendo assim, formam um grande "guarda-chuva" que
quando previsto não possuem detalhamento de
funcionalidades ou requisitos, podendo ter duração de 1 à
3 meses.
Já as histórias de usuário consistem nas especificações
dos épicos, onde as features possuem requisitos
funcionais, não funcionais e critérios de negócios.
As histórias de usuário, ao contrário dos épicos, possuem
uma duração menor, em sua maioria com duração de uma
semana.

3. Antes de tudo: épicos vs. user stories

4. Antes de tudo: épicos vs. user stories
Épico: “Uma funcionalidade que permita gerir a ordem de pedidos na fila”
US 1
Como GERENTE DO RESTAURANTE, preciso visualizar os pedidos da fila para saber quais preciso
gerenciar.
US 2
Como GERENTE DO RESTAURANTE, preciso visualizar os itens e quantidade de itens de um pedido
da fila para saber quais levam mais tempos para serem preparados.
US 3
Como GERENTE DO RESTAURANTE, preciso visualizar a hora que um pedido foi aberto para saber a
quanto tempo está esperando.
US 4
Como GERENTE DO RESTAURANTE, preciso mudar a ordem dos pedidos para otimizar a fila do
restaurante

5. User Stories
O que são e do que se alimentam?

6. User stories - ou histórias de usuários -
é uma forma simplificada de descrever
funcionalidades a serem desenvolvidas
de acordo com a perspectiva do
usuário final.
Histórias de usuário podem contar com
a perspectiva de um ou mais usuários
finais, não tendo necessidade de ser
completa, favorecendo a geração de
valor incremental.
Fonte das imagens: https://www.synergia.dcc.ufmg.br/

7. As histórias de usuário devem conter três pontos essenciais:
Como (sujeito – cliente)
Eu quero (ação – objetivo)
Para (necessidade – desejo – valor atribuído)
A perspectiva de valor a partir das histórias de usuário
possibilita ao time tomadas de decisões assertivas, mais
alinhadas com a necessidade do usuário final.
Ou seja, histórias de usuário bem especificadas oportunizam
ganhos significativos quando o assunto é qualidade!

8. Conforme o exemplo podemos identificar que
constam as três informações fundamentais
para compor uma história. Sendo:
Quem? Para quem estamos desenvolvendo a
funcionalidade.
O que? Uma descrição resumida da
funcionalidade em si.
Por que? O motivo pelo qual o cliente precisa
desta funcionalidade. Se possível citando o
valor de negócio obtido.
Da escrita ao valor: como escrever user stories

9. Da escrita ao valor: como escrever user stories
Outro ponto muito importante que decorre
das histórias de usuário são os critérios de
aceite.
É a partir deles que o team dev terá maiores
detalhes para trabalhar em itens (subtasks)
que completem o valor da história.

10. Testes de User stories e critérios de aceite com Behavior Driven Development
O Behavior Driven Development, também
conhecido como BDD, nada mais é que a
formação de possíveis cenários práticos através
de sentenças.
Dado que posso alterar os meus dados cadastrais
no App 2.0 é possível
Quando informo o meu novo e-mail
Então meus dados são atualizados
E recebo a confirmação por e-mail
Ou SMS (celular)
No exemplo ao lado podemos notar três
elementos propulsores para criar as
sentenças teste:
Dado que – indica o cenário atual
Quando – indica a ação do usuário
Então – indica como o software vai reagir
Além deles, ainda podemos utilizar E / Ou
quando pretende-se trazer uma maior
complexidade ao cenário.
BDD é um método criado por Dan North. Para maiores informações consultar <https://dannorth.net/introducing-bdd/>

11. INVEST
Outro método utilizado para revisar histórias
de usuário é o INVEST.
Esse acrônimo auxilia na validação de qualidade da história.

12. E o tamanho da história?
O tamanho ideal de uma história, deve ser
maior do que um dia e levar até uma semana
para ser finalizada.
Caso uma história seja menor que um dia, será
avaliada como task, por não se enquadrar, por
exemplo, nos critérios invest.
Quanto ao tamanho máximo ideal, devemos considerar
que uma história que demanda mais de uma semana
geralmente compreende uma alta complexidade. Sendo
assim, podemos verificar a possibilidade de quebrar essa
história em duas ou mais.

13. Prioridades, bb! Por onde começar?
A entrega de valor está diretamente ligada
à percepção do cliente sobre um produto
ou serviço.
Isso quer dizer que quando uma pessoa consome
um produto, ela está buscando mais do que a
principal necessidade atendida por ele.
O conceito de valor na agilidade consiste nesse
plus, em tudo aquilo que potencializa um produto
ou serviço [fator WOW].

14. Prioridades, bb! Por onde começar?
Mindset
Necessidade
Flutuações
de mercado

15. Story Points: sequência Fibonacci
Story Points são abstrações que possibilitam
medir o tamanho de cada história. Eles nos
ajudam a estimar desde a complexidade à
datas de entrega.
A Sequência Fibonacci é uma das formas mais
utilizadas para vincular story points às histórias
de usuário.
Planning Poker

16. Story Points: sequência Fibonacci
A ideia de utilizar a Sequência Fibonacci é para poder
estimar, a partir de intervalos numéricos, tamanho,
tempo de desenvolvimento e complexidade.
Quando o time está estimando itens menores de
tamanho como 1, 2 e 3, tendem a ter maior
assertividade de estimativa.
No entanto, se o item está entre 5 , 8 e 13,
podemos observar o salto na sequência, o que exige
discussões sobre pontos de vista, ​estimativas e
riscos.

17. Bugs,
Sustentações e
Incidentes

18. E o que fazer quando dá treta? História de Usuário?
NÃO! Histórias de usuário não devem ser atribuídas para itens de
sustentação, bug, incidente ou débito técnico.
Para isso podemos utilizar o modelo sugerido a seguir:
Local: Nome do sistema [módulo e menu se houver]
Versão: Indicar a versão na qual o problema ocorre
Pré-condições: O que deve ser configurado, podendo ser uma lista de configurações ou indicação específica
de uma base de dados que possa ser utilizada
Passos para a reprodução do erro: Lista indicando os passos a serem realizados para repetir o erro e
identificar o que deve ser preenchido em cada campo [é importante considerar que qualquer pessoa possa
repetir o erro consultando esse material]
Erro: Identificar o que está acontecendo considerando também o atual contexto de negócio
Situação desejada: Descrever onde se pretende chegar com a correção, identificando configurações que
não foram consideradas anteriormente e o que deve ser modificado de acordo com as regras de negócio.

19. E como diria Rafael Helm...
"Qualidade de software
começa na especificação"

20. Referências bibliográficas
2
HELM, Rafael; WILDT Daniel. Histórias de usuário:
por que e como escrever requisitos de forma
ágil?. Historiadeusuario.com.br, 3a edição.
BOEG, Jesper. Kanban em 10 passos. Otimizando o
fluxo de trabalho em sistemas de entrega de
sotware. InfoQBrasil.
ANDERSON, J. David. Kanban: Mudança
Evolucionária de Sucesso para seu Negócio de
Tecnologia. Ed. Blue Hole Press.