1) O documento discute os princípios e melhores práticas para escrever histórias de usuário, incluindo o que constitui uma boa história e como evitar erros comuns.
2) É explicado que histórias de usuário devem se concentrar na perspectiva e necessidades do usuário final, não do time de desenvolvimento.
3) Diferentes modelos para estruturar histórias de usuário são apresentados, assim como dicas para escrever histórias que sejam independentes, negociáveis e de pequeno escopo.
Nesta webinaula, promovida pela Projectlab, apresentei alguns conceitos e práticas que um bom PO deve conhecer para exercer seu papel dentro do framework Scrum.
O Time recebe as USs para desenvolver, mas será que sabem por que existem? O que pode conter? E que a melhor forma de uma US é a que o Time definir junto ao papel de PO/ PM! Este papel não precisa trabalhar de maneira solitária e entregando USs ao Time, deve parear com pessoas técnicas, assim as pessoas desenvolvem a visão técnica x negócio, apoiando ter um Time full stack. Além disso o papel PO/ PM pode focar mais nas descobertas do produto e o time pode apoiar na escrita de histórias do usuário. Junto a qualidade deve estar em todo processo de desenvolvimento e é responsabilidade de todo Time, o QA review pode auxiliar promovendo o alinhamento e a análise do que tem de ser desenvolvido. USs e QA review promovem a conversa para que visões diferentes sejam complementares para entrega de um produto com valor e qualidade, com foco na pessoa usuária. Este workshop tem o objetivo de promover time autônomos.
Dúvidas, sugestões e feedback:
Mayra Souza
mayra.souza@zapcorp.com.br
https://br.linkedin.com/in/mayrarodriguesdesouza
@paola_mayra
Eluza Pinheiro
eluzapinheiro@gmail.com
https://www.linkedin.com/in/eluzapinheiro/
@usinadeux
Referências:
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
http://www.knowledge21.com.br/sobreagilidade/user-stories/o-que-e-user-story/
https://www.agilealliance.org/glossary/invest/
https://www.slideshare.net/tdc-globalcode/tdc2016poa-trilha-analise-de-negocios-como-fatiar-seu-produto-em-estrias-que-faam-sentido
https://www.slideshare.net/augustoruckert/historias-de-usuarios-declarao-de-valor
O que Evitar na Escrita de Criterios de AceiteElias Nogueira
Palestra ministrada no The Developers Conference 2016 Porto Alegre dia 07/10/2016 e no The Developers Conference 2017 Florianópolis no dia 04/05/2017 apresentando alguns anti padrões na escrita de Critérios de Aceite.
Experiência do Usuário e Jornada do Usuário Raiana Comiran
Palestra feita na semana de empreendedorismo da UFFS em Chapecó sobre experiência do usuário com foco no método da Jornada do Usuário, onde os participantes realizaram a jornada de de uma persona que queria um hotel e/ou airbnb e ficar 10 dias :)
Nesta webinaula, promovida pela Projectlab, apresentei alguns conceitos e práticas que um bom PO deve conhecer para exercer seu papel dentro do framework Scrum.
O Time recebe as USs para desenvolver, mas será que sabem por que existem? O que pode conter? E que a melhor forma de uma US é a que o Time definir junto ao papel de PO/ PM! Este papel não precisa trabalhar de maneira solitária e entregando USs ao Time, deve parear com pessoas técnicas, assim as pessoas desenvolvem a visão técnica x negócio, apoiando ter um Time full stack. Além disso o papel PO/ PM pode focar mais nas descobertas do produto e o time pode apoiar na escrita de histórias do usuário. Junto a qualidade deve estar em todo processo de desenvolvimento e é responsabilidade de todo Time, o QA review pode auxiliar promovendo o alinhamento e a análise do que tem de ser desenvolvido. USs e QA review promovem a conversa para que visões diferentes sejam complementares para entrega de um produto com valor e qualidade, com foco na pessoa usuária. Este workshop tem o objetivo de promover time autônomos.
Dúvidas, sugestões e feedback:
Mayra Souza
mayra.souza@zapcorp.com.br
https://br.linkedin.com/in/mayrarodriguesdesouza
@paola_mayra
Eluza Pinheiro
eluzapinheiro@gmail.com
https://www.linkedin.com/in/eluzapinheiro/
@usinadeux
Referências:
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
http://www.knowledge21.com.br/sobreagilidade/user-stories/o-que-e-user-story/
https://www.agilealliance.org/glossary/invest/
https://www.slideshare.net/tdc-globalcode/tdc2016poa-trilha-analise-de-negocios-como-fatiar-seu-produto-em-estrias-que-faam-sentido
https://www.slideshare.net/augustoruckert/historias-de-usuarios-declarao-de-valor
O que Evitar na Escrita de Criterios de AceiteElias Nogueira
Palestra ministrada no The Developers Conference 2016 Porto Alegre dia 07/10/2016 e no The Developers Conference 2017 Florianópolis no dia 04/05/2017 apresentando alguns anti padrões na escrita de Critérios de Aceite.
Experiência do Usuário e Jornada do Usuário Raiana Comiran
Palestra feita na semana de empreendedorismo da UFFS em Chapecó sobre experiência do usuário com foco no método da Jornada do Usuário, onde os participantes realizaram a jornada de de uma persona que queria um hotel e/ou airbnb e ficar 10 dias :)
What are User Stories? How should we write them? How to write them well?
Effective User Stories allow your team to be effective (deliver want the User needs) and efficient (Deliver it quickly and importantly don't deliver unneeded features).
How to organize a user story writing workshop. An overview for Scrum Masters, Product Owners, and others wanting to organize creation of an agile product backlog
Writing Good User Stories (Hint: It's not about writing)one80
User stories are typically the foundation of the Product Backlog. However, the original purpose has been lost. This is from a presentation that was given to help remind everyone of what User Stories are, and what they aren't. The purpose of User Stories is to drive conversations, not to hand "requirements" from one group to the next.
"How to write better User Stories" por @jrhuertawebcat
Presentación realizada en el #webcat Barcelona de Abril 2013
Autor: José E. Rodríguez (@jrhuerta)
------------------------------------------------
RECURSOS:
- Agile Barcelona
http://agile-barcelona.org/
- "User Stories Applied: For Agile Software Development", Mike Cohn, 2004, Addison-Wesley Professional
http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
- "Lean UX", Jeff Gothelf & Josh Seiden, 2012, O'Reilly Media
http://www.leanuxbook.com/
[Pcamp19] - Desmistificando o processo de Discovery - Camila Ferreira | Cred...Product Camp Brasil
1) Como fazemos o processo de Discovery Contínuo na Creditas; 2) Como alinhamos com stakeholders todas as iniciativas; 3) Qual o papel de Analytics no discovery de novas iniciativas; 4) Como fazemos o estudo técnico e estimativa de esforço das iniciativas; 5) Quais os ganhos, qualitativos e quantitativos, com esse novo processo.
Gathering and defining software requirements is difficult. One Agile technique to help address this challenge is writing user stories, which are short descriptions of functions that an end-user would want. While user stories help convert concepts into functions, writing good user stories is easier said than done.
What you’ll learn in this presentation:
• The basics of user stories.
• How user stories fit into the overall Agile planning process.
• How to write a user story.
This presentation discusses how to split user stories using INVEST, a mnemonic created by Bill Wake. Mike Harris presented this presentation at Agile Philly.
Especificações funcionais e requisitos de conteúdoDavi Denardi
Apresentação da disciplina de Web Design do curso de graduação em Design Gráfico da Faculdade Satc de Criciúma.
Aula 5 - Especificações funcionais e requisitos de conteúdo.
Porque Story Points São Muito Melhores do que HorasLeandro Faria
Leandro Faria apresenta neste talk conceitos que mostram porque Story Points são muito melhores do que horas, considerando estimativas de tamanho e esforço em projetos de software.
User stories are supposed to reflect the ‘human’ side of the IT. The should be easy to understand and not too technical. Ok, but what should happen when you’re asked to prepare user stories for strictly technical projects/products?
Outline
Understanding target audiences
Understanding scope
Use or not to use user stories -> scope management
Fitting the requirements to ‘user stories’ oriented tools
Why should you hear this talk? How to deal with technical User Stories in Scrum? Is it possible to write good technical User Story? Find out during my talk!
What are User Stories? How should we write them? How to write them well?
Effective User Stories allow your team to be effective (deliver want the User needs) and efficient (Deliver it quickly and importantly don't deliver unneeded features).
How to organize a user story writing workshop. An overview for Scrum Masters, Product Owners, and others wanting to organize creation of an agile product backlog
Writing Good User Stories (Hint: It's not about writing)one80
User stories are typically the foundation of the Product Backlog. However, the original purpose has been lost. This is from a presentation that was given to help remind everyone of what User Stories are, and what they aren't. The purpose of User Stories is to drive conversations, not to hand "requirements" from one group to the next.
"How to write better User Stories" por @jrhuertawebcat
Presentación realizada en el #webcat Barcelona de Abril 2013
Autor: José E. Rodríguez (@jrhuerta)
------------------------------------------------
RECURSOS:
- Agile Barcelona
http://agile-barcelona.org/
- "User Stories Applied: For Agile Software Development", Mike Cohn, 2004, Addison-Wesley Professional
http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
- "Lean UX", Jeff Gothelf & Josh Seiden, 2012, O'Reilly Media
http://www.leanuxbook.com/
[Pcamp19] - Desmistificando o processo de Discovery - Camila Ferreira | Cred...Product Camp Brasil
1) Como fazemos o processo de Discovery Contínuo na Creditas; 2) Como alinhamos com stakeholders todas as iniciativas; 3) Qual o papel de Analytics no discovery de novas iniciativas; 4) Como fazemos o estudo técnico e estimativa de esforço das iniciativas; 5) Quais os ganhos, qualitativos e quantitativos, com esse novo processo.
Gathering and defining software requirements is difficult. One Agile technique to help address this challenge is writing user stories, which are short descriptions of functions that an end-user would want. While user stories help convert concepts into functions, writing good user stories is easier said than done.
What you’ll learn in this presentation:
• The basics of user stories.
• How user stories fit into the overall Agile planning process.
• How to write a user story.
This presentation discusses how to split user stories using INVEST, a mnemonic created by Bill Wake. Mike Harris presented this presentation at Agile Philly.
Especificações funcionais e requisitos de conteúdoDavi Denardi
Apresentação da disciplina de Web Design do curso de graduação em Design Gráfico da Faculdade Satc de Criciúma.
Aula 5 - Especificações funcionais e requisitos de conteúdo.
Porque Story Points São Muito Melhores do que HorasLeandro Faria
Leandro Faria apresenta neste talk conceitos que mostram porque Story Points são muito melhores do que horas, considerando estimativas de tamanho e esforço em projetos de software.
User stories are supposed to reflect the ‘human’ side of the IT. The should be easy to understand and not too technical. Ok, but what should happen when you’re asked to prepare user stories for strictly technical projects/products?
Outline
Understanding target audiences
Understanding scope
Use or not to use user stories -> scope management
Fitting the requirements to ‘user stories’ oriented tools
Why should you hear this talk? How to deal with technical User Stories in Scrum? Is it possible to write good technical User Story? Find out during my talk!
Proposta para especificação de histórias de usuários alinhadas a IEEE 830André Agostinho
Uma proposta para especificação de user stories utilizando a engenharia centrada a uso e criando especificações de requisitos alinhadas a prática a IEEE 830. A proposta considera ainda o uso da metodologia ágil Scrum e da técnica BDD para testar e validar user stories, além de fornecer living documentation para e equipe de desenvolvimento e do cliente.
Tell me what you want - Uma visão sobre análise de requisitosJuliano Ribeiro
Palestra dada no TDC Porto Alegre, em 2013. Nela falo um pouco sobre os métodos que tive contato para fazer levantamento de requisitos e qual foi a minha experiência dentro dessa área.
Palestra sobre testes, mais especificamente para projetos Drupal, que aborda as diferentes práticas de testes. TDD, TAD, BDD, Testes de aceitação... Ministrada pelo João Paulo Seregatte, Head de Tecnologia da Just Digital. Além se dar bastante ênfase nas práticas de teste, o conteúdo aborda práticas de escrita de User Stories. A palestra é voltada para Agile Test.
Como utilizar ferramentas de testes em um projeto Drupal utilizando metodologias ágeis?
Nessa palestra vamos apresentar conceitos e formas de implementar uma feature testável em um site Drupal.
Trabalharemos em um projeto fictício pensando de uma forma orientada a testes e como e quais são os papéis de um time ágil que devem se envolver neste processo.
No final temos um módulo pronto, testável e disponível via github (https://github.com/seregatte/palestra-agile-testing-no-drupal).
A arte de escrever US - Agile brazil 2017Thiago Luna
Esta apresentação foi utilizada no workshop "A arte de escrever user story: Quais são os segredos", apresentado no Agile Brasil 2017, realizado em Belém.
Feature Injection - Descobrindo e entregando valor testávelHélio Medeiros
A Injeção de Funcionalidades é um Processo de Análise de Negócios criado por Chris Matts para resolver esse problema! Esta foi minha palestra no TDC 2014
O workshop da jornada do cliente (ou mapa de experiência) tem como objetivo mapear todo o processo pelo qual os clientes passam. Pode ajudar a examinar o que acontece antes de um cliente usar um produto/serviço pela primeira vez, e após seu uso também. Durante este workshop da jornada do cliente, muitas coisas antes inimagináveis surgirão.
Conceito da experiência do cliente
Ciclo de vida do cliente
Transformação e Inovação Centrado no Cliente
Canvas da Jornada do Cliente
Semelhante a Histórias de usuários - Declaração de valor (20)
Valide no papel: Prototipagem e testes de interfaces mobile - versão 2Augusto Rückert
A prototipagem em papel é uma maneira rápida de iniciar a criação do seu aplicativo mobile de modo consistente e testável. Utilizando técnicas simples e rápidas de prototipagem de interfaces, somente com papel e caneta, é possível iterar ideias e soluções de modo ágil e incremental. Ao associar esses protótipos rápidos, com técnicas de testes de usabilidade de guerrilha, podemos validar o aplicativo de forma eficaz diretamente com público alvo, mesmo antes de escrever a primeira linha de código.
Os protótipos em papel são eficazes por diminuir significativamente os riscos existentes na criação de um novo produto mobile, por um custo muito baixo. Além disso, devido a simplicidade do protótipo em papel, há uma fácil dissociação das possíveis dificuldades técnicas e do estilo visual, focando no valor a ser entregue e na qualidade da interação.
Versão apresentada no TDC SP 2017
Valide no Papel: Prototipagem e testes de interfaces mobileAugusto Rückert
A prototipagem em papel é uma maneira rápida de iniciar a criação do seu aplicativo mobile de modo consistente e testável. Utilizando técnicas simples e rápidas de prototipagem de interfaces, somente com papel e caneta, é possível iterar ideias e soluções de modo ágil e incremental. Ao associar esses protótipos rápidos, com técnicas de testes de usabilidade de guerrilha, podemos validar o aplicativo de forma eficaz diretamente com público alvo, mesmo antes de escrever a primeira linha de código.
Os protótipos em papel são eficazes por diminuir significativamente os riscos existentes na criação de um novo produto mobile, por um custo muito baixo. Além disso, devido a simplicidade do protótipo em papel, há uma fácil dissociação das possíveis dificuldades técnicas e do estilo visual, focando no valor a ser entregue e na qualidade da interação.
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. 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
Relembrando o manifesto ágil...
11. 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
16. Cartão
Conversação
Confirmação
A demanda deve ser sucinta e compreensível por todos. A história é
descartável, não um requisito a ser rastreado.
3Cs
Componentes da histórias de Ron Jeffries
17. Cartão
Conversação
Confirmação
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.
3Cs
Componentes da histórias de Ron Jeffries
24. Exemplo 1
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)
25. Exemplo 2
Sendo um Administrador de Redes
quero filtrar os IPs por subrede
pois quero poder agrupá-los para melhorar a
organização da minha infraestrutura
Modelo Connextra (padrão mais conhecido)
26. Mike Cohn
Como um <papel/persona/perfil>
quero/preciso/necessito de <meta/desejo>
Variações do Modelo Connextra
27. Mike Cohn
Como um Vendedor
quero listar todos os pedidos de um cliente
Variações do Modelo Connextra
28. Chris Matts
A fim de <benefício a ser recebido>
como um <papel/persona/perfil>,
eu quero <meta/desejo>
Variações do Modelo Connextra
29. 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
30. Variações do Modelo Connextra
5Ws (Who, When, Where, What, Why)
Como <quem>,
<quando> <onde>,
eu <o que>,
porque <por que>
31. 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
32. 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>
33. 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
38. 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
39. 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
40. 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
41. 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
43. Avalie a zona de controle
e a esfera de influência
!. Escrevendo histórias melhores.
44. 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...
45. 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...
46. 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...
47. 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...
48. 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
49. 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
50. Uma boa história implica
em ter algum risco
!. Escrevendo histórias melhores.
52. 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...
53. Devemos evitar quebrar os itens em tamanhos menores
até o momento que seja necessário adicionar mais
informações específicas, antes de precisarmos começar a
trabalhar nesses itens.
Um backlog eficiente está estruturado de forma hierárquica. Nele há vários
tamanhos de histórias…
O quão MICRO?!?
54. Um backlog linear, somente com elementos do mesmo
tamanho, ou não permite um planejamento preciso (pois
os itens são muito grandes) ou não permite uma visão e
entrega completa do valor (pois os itens são muito
pequenos).
O backlog deve ser hierárquico para garantir uma visão completa do que
está sendo entregue.
O quão MICRO?!?
56. Jeff Patton nos diz para pensar em Asteroids…
1. Você precisa quebrar os asteróides grandes até deixá-los
tão pequenos que um raio laser certeiro seja capaz de
destruí-lo.
57. Jeff Patton nos diz para pensar em Asteroids…
1. Você precisa quebrar os asteróides grandes até deixá-los
tão pequenos que um raio laser certeiro seja capaz de
destruí-lo.
2. Mas não pode sair fragmentando todos, senão fica
impossível de navegar e manobrar.
58. Jeff Patton nos diz para pensar em Asteroids…
1. Você precisa quebrar os asteróides grandes até deixá-los
tão pequenos que um raio laser certeiro seja capaz de
destruí-lo.
2. Mas não pode sair fragmentando todos, senão fica
impossível de navegar e manobrar.
3. Tem que manter um bom número de asteróides medianos
para saber o que vai vir e fragmentar aqueles que dá conta de
eliminar de verdade.
61. 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...
64. Como desenvolvedor, eu preciso
eliminar as tabelas duplicadas da base
de dados
?. Quando não é uma história.
65. 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.
66. Como testador, eu preciso preparar o
plano de testes da versão 3.5
?. Quando não é uma história.
67. Por que esses enunciados não são
histórias de usuário?
?. Quando não é uma história.
68. 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?
69. Não se trata de um usuário
Não é uma requisição de uso para a persona
Não traz valor para o negócio
Por que não é uma história?
70. Se não traz valor para o usuário,
por que fazemos?
?. Quando não é uma história.
71. Bem mais fácil gerar funcionalidades desnecessárias quando fazemos o que queremos
72. Eliminar os desperdícios
Devemos eliminar da cadeia de valor tudo que não gera valor
Mas precisamos manter o que evita a perda de valor
Um pouco de pensamento Lean
73. Quando é algo que precisamos fazer
!. Quando não é uma história.
76. 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
77. 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
78. Elicite 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
80. Elicite 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
82. Quando é uma pergunta
!. Quando não é uma história.
83. Quando é uma pergunta
Há algo a ser feito, mas não sabemos como
!. Quando não é uma história.
84. Se quem fez a requisição não sabe o que quer, vamos descobrir juntos
85. 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...
86. 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
88. 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
89. 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