Se eu tiver uma idéia na minha cabeça e escreve-lá, quando você ler provavelmente vai imaginar alguma coisa diferente.
Se você me disser o que pensa, eu posso te fazer perguntas e podemos externalizar essas idéias para criar uma entendimento compartilhado.
Não se trata de quem está certo ou errado mas que todos nós vemos de forma diferente alguns aspectos.
Combinando e refinando nossas diferentes idéias, conseguimos um entendimento comum que inclui as melhores delas. Desenhamos e criamos notas com sticky notes porque palavras sozinhas são difíceis para nos envolvermos no entendimento compartilhado.
Compartilhar documentos não é o mesmo que compartilhar o entendimento.
Vá em frente e escreva alguma coisa. Então use conversas produtivas com palavras e figuras para construir um entendimento compartilhado. O real objetivo do uso das stories é o entendimento compartilhado.
Stories têm esse nome de acordo como elas devem ser utilizadas. Se você está criando stories sem utilizar palavras e figuras, está fazendo isso errado.
Um processo dirigido à stories precisa de muitos documentos para funcionar. Mas não são documentos tradicionais.
Durante o processo escrevemos e desenhamos bastante para descrever as stories que queremos contar. O importante não é a quantidade de material produzido mas sim o que eles nos fazem lembrar. Melhor do que tirar fotos é gravar um video da conversa.
Qualquer grande idéia que você transforma em produto muda o mundo de alguma maneira, no modo em que as pessoas vão utilizar. Se isso não acontecer então você falhou.
Existe um modelo chamado "mude o mundo" que você deve ter em mente quando estiver conversando e construindo o entendimento. Esse modelo começa olhando como o mundo é hoje para procurar pessoas que estão infelizes, tristes, confusas ou frustradas. Porém o mundo é um lugar imenso, então vamos focar nas pessoas que usam nosso produto ou esperamos que vão utilizar.
Quando você enxerga o que elas estão fazendo e quais ferramentas elas usam e como elas estão fazendo as coisas, você vai despertar novas idéias que podem servir para:
- Produtos novos que você pode construir
- Funcionalidades para adicionar em produtos existentes
- Melhorias em produtos que você já construiu
Com essas idéias nós vamos inseri-las em algum processo que vai resultar em algum software que esperamos deixar as pessoas felizes. Elas ficarão felizes porque farão coisas diferentes devido ao produto que nós construímos.
Tudo entre a idéia e a entrega é chamado output. Isso é tudo que construímos. Alguns gestores tentam medir e aumentar a velocidade do output. Entretanto o output não é o que realmente importante pois não é o que queremos. O que importa é o que vem como resultado disso, que chamamos de outcome. E difícil medir o outcome enquanto não temos um resultado. Nós não medimos o resultado em número de funcionalidades entregues ou que as pessoas são capazes de fazer agora. Nós medimos pelos objetivos alcançados e como melhoramos a vida delas.
Nas conversas sobre funcionalidades, devemos saber para quem é, como fazem hoje e como vamos melhorar a vida das pessoas depois. Boas stories são sobre como e por quê, não apenas o que.
Não é totalmente verdade que o importante é apenas deixar os usuários felizes. Você também precisa ajudar sua empresa à ganhar mais dinheiro ou expandir mercado, por exemplo.
A verdade é que sua empresa não pode ter o que quer a menos que seus clientes e usuários tenham alguma coisa que eles queiram. Chamamos de impacto a consequência de bons resultados. Resultados são coisas que você pode observar após uma entrega mas impacto leva tempo.
Sempre existe mais a ser construído do que temos tempo e recursos para construir. Sempre.
Um mal entendido comum em desenvolvimento de software é tentar entregar mais rápido. Faz sentido que há muito a ser feito então fazer mais rápido deveria ajudar, certo? Errado. Seu trabalho não é construir mais e sim contruir menos.
Construir software mais rápido sempre é uma boa idéia mas nunca a solução. Minimize o output, maximize o outcome e o impacto! No final do dia, esse é o seu trabalho.
Preste atenção nas pessoas cujos problemas você tenta resolver. Isso inclui as pessoas que compram o software e as pessoas que vão utiliza-lo. Nem sempre são os mesmos. A estratégia de negócios deve guia-lo sobre em quem focar para criar o impacto que você quer.
Story Mapping é um jeito de trabalhar com user stories em processos ágeis. É um pattern. É para quebrar grandes stories como você as conta. É sobre ter uma boa e velha conversa e organizar isso em forma de mapa. Conversando podemos construir um entendimento compartilhado e juntos encontrar a melhor solução.
Com o mapa montado, as pessoas vão olhar e ter um entendimento sobre o produto, porém a parte mais importante está ao redor do mapa, que são os objetivos do produto. Depois é preciso trabalhar duro para minimizar a idéia do produto em algo que seja factível de fazer primeiro.
Converse e escreva. Não deixe as palavras vaporizarem. Escreva em sticky notes e então você pode voltar nelas depois.
Tenha sempre o hábito de escrever suas idéias antes de explica-las. Escreva algumas palavras sobre a idéia imediatamente após pensar nelas. Depois explique sua idéia, desenhe e conte stories. Por fim, posicione seu stick note em um espaço compartilhado onde todos possam ver e interagir.
Durante as conversas, tente entender qual o resultado que o cliente espera e não o que ele quer construir.
Descreva os objetivos em sticky notes separados, coloque um sobre o outro induzindo uma ordem de prioridade, mas propositalmente coloque fora de ordem e peça para o cliente priorizar. Faça as perguntas abaixo para entender quais os resultados desejados:
- O que é isso?
- Por que construir isso?
- O que vai acontecer depois de construido?
Tente identificar quem compra e quem vai usar o software com perguntas como:
- Por que eles vão utilizar o produto?
- O que nós achamos que eles vão fazer com o produto?
Descreva os tipos de usuários e adicione 2 sentenças sobre eles. Depois descreva os tipos de atividades que as pessoas deveriam realizar com o produto. Peça ao cliente para escolher um cliente para focar as stories.
Vamos imaginar por um minuto que o produto está pronto e vamos discutir sobre o dia-a-dia na vida de quem vai utiliza-lo contando uma estória. Primeiro ele tem que fazer isso, então aquilo e depois aquilo outro...
Então organizamos isso em cards numa ordem da esquerda para a direita. O objetivo é organizar os cards juntos permitindo contar uma estória sem dizer uma palavra. Mapear as stories nos ajuda a encontrar buracos nos pensamentos.
Precisamos ter cuidado para não nos perder nos detalhes, especialmente quando quem está contando a estória tem uma certa paixão por ela. Vá para o final da estória antes de se perder nos detalhes.
Quando a estória estiver grande, separe os passos dela em cards ao lado do card da estória, da esquerda para direita.
Crie um card para a estória, adicione os passos logo abaixo numa sequencia lógica da esquerda para direita e abaixo de cada passo adicione cards contendo os detalhes do passo. Utilize frases curtas começando com verbos para descrever os passos da estória.
Crie um mapa da release do produto entre multiplos times para visualizar as dependências.
Jogue o jogo do "e-se" para considerar opções e alternativas, fazendo perguntas como "e se isso der errado?" e "e se incluírmos esses outros usuários?". Quando você joga isso com outros times consegue encontrar falhas que podem existir quando sistemas diferentes se conectam.
Concentre-se no que você espera que aconteça fora do sistema para tomar decisões sobre o que está dentro do sistema.
Concentre-se nos resultados. No que os usuários precisam ver e fazer quando o sistema for lançado. Faça uma linha para marcar quais stories fazem sentido entrar em cada release.
Cada release deve atacar um dos resultados esperados. Assim fica fácil entender qual o real objetivo de cada release e criar um roadmap de releases.
As releases não são um conjunto de features e sim uma lista de benefícios que o software vai trazer para resolver algum problema do mundo real. Foco nos resultados esperados é o segredo para priorizar o que tem que ser feito.
É um termo originalmente criado por Frank Robinson cuja definição criada por Eric Ries e Steve Blank domina nos dias atuais. É um termo que causa muita confusão resultando em diferentes interpretações.
MVP não é um produto que seus usuários podem utilizar, somente em algumas circunstâncias e somente se eles têm muita paciência. Colocar um MVP em produção é pior do que não colocar nada.
O MVP é o menor produto capaz de atingir um resultado esperado com sucesso. Deveria ser chamado de MVS (minimum viable solution). Faz mais sentido.
O problema com os resultados é que você não pode realmente observá-los até que as coisas saem. Então quando você define o que vai ter numa release, você apenas tem uma hipótese do que vai acontecer. Apenas supõe o motivo pelo qual o software vai ser comprado ou utilizado. E isso é ruim pois se sua release tiver stories insuficientes para alcançar o resultado, você falhou. Se tiver muito mais do que o necessário então significa que o custo e o tempo foram altos e ainda há o risco de não dar certo.
Quais são nossos maiores riscos? Onde estão as incertezas? O que podemos fazer para aprender alguma coisa para substituir os riscos e incertezas por informações verdadeiras?
Eric trabalhou para uma empresa que lançou um produto que parecia viável mas não era. Então ele mudou a estratégia para focar no aprendizado, validando as hipóteses através do MVP. Nesse caso ele criou pequenos experimentos para validar o que é viável.
O MVP é a menor coisa que você pode criar para provar ou não uma hipótese.
Uma das partes mais difíceis de ser Product Owner é sentir como se fosse o dono da idéia de alguém e ter que ajudar a transforma-lá em sucesso ou provar que a idéia não vale a pena. O PO deve ajudar o time inteiro a se sentir dono do produto.
Não comece criando um backlog de user stories. Comece conversando sobre:
- Qual é a grande idéia?
- Quem são os clientes? Quem vai comprar?
- Quem são os usuários? Quais os tipos de usuários e o que eles precisam para usar?
- Por que eles vão querer usar o produto? Quais os problemas que devem ser resolvidos e que não podem ou não foram resolvidos hoje? Quais os benefícios que o produto vai trazer para quem o utiliza?
- Por que vamos construir? Se construírmos o produto e ele for um sucesso, como isso vai nos ajudar?
Sua primeira discussão de story é para enquadrar a oportunidade.
Toda grande idéia é uma hipótese que deve ser validada. Você deve conversar diretamente com os clientes e usuários para realmente aprender sobre eles. Então entender se realmente eles têm um problema e se estão interessados em pagar por uma solução. Quanto mais você aprende sobre a solução, mais a oportunidade original se altera - eventualmente até demais. Enquanto voê conversa com as pessoas, atente para quais podem ser bons candidatos para testar o novo software. Algumas empresas se referem à essas pessoas como customer development partners.
Após essas conversas você já pode começar a criar as stories.
Imagine um monte de stories simples - user scenarios. Então desenhe wireframes para esboçar as idéias. Depois construa protótipos de alta fidelidade, utilizando alguma ferramenta digital, podendo ser até mesmo o power point. Tudo isso serve para ajudar a imaginar a solução. Por último, coloque a solução na frente dos usuários para ver como eles reagem e o que pensam.
Esteja preparado para surpresas e más notícias. Na verdade, comemore as más notícias, porque você as recebeu muito antes de começar a desenvolver o software.
Prototipe e teste com os usuários para saber se sua solução é viável e utilizável.
Se você mostrar às pessoas todas as idéias legais, é óbvio que eles vão ama-las. Seu trabalho é diminuir a quantidade de coisas construídas mas mantendo as pessoas felizes.
Clientes e usuários podem imaginar o produto como uma coisa incrível. Mas a prova real é eles escolherem utilizar o produto no dia-a-dia. Esse é o resultado real que buscamos.
Antes de construir um protótipo, faça menos ainda, construa o mínimo suficiente para que potenciais usuários possam fazer alguma coisa útil com isso. Esse produto não deve impressionar muita gente e as pessoas provavelmente não vão gostar dele. Não é um produto que as pessoas de vendas e marketing devam interagir. Você deve mostrar esse produto apenas para as pessoas que vão utiliza-lo no dia-a-dia e estão preocupadas com ter seus problemas resolvidos.
Pessoas são educadas e mesmo que não gostem vão mentir. Mas as métricas vão nos dizer a verdade.
Em cada release você deve entregar alguma coisa que a pessoa vá utilizar. Trate todas as releases como uma experiência e esteja atento ao que deseja aprender.
Validated Learning Strategy é um dos conceitos mais importantes em Lean Startup Thinking. A cada passo que você construir algo, analise as métricas.
Informações sobre product discovery podem ser encontradas no livro "Inspired: How to Create Products Customers Love".
Se reconhecermos que nosso objetivo é aprender, podemos minimizar o que construímos e nos concentrar em construir apenas o que precisamos aprender.
Algumas pessoas acreditam erroneamente que precisam mapear o produto inteiro para fazer uma pequena mudança, e elas usam isso como desculpa para não mapear. Mapeie apenas o que você precisa para ajudar na conversa.
Mostre ao time o passo a passo das stories a partir da perspectiva do usuário. Utilize protótipos se precisar.
O time precisa ter todas as respostas em relação ao comportamento do usuário. Quando não há as respostas, converse com o time para ouvir o que eles propõem, adcione novos sticky notes e rabisque à vontade os protótipos.
As melhores estimativas vêm de desenvolvedores que realmente entendem o que estão estimando.
Para melhorar o entendimento dos desenvolvedores podemos utilizar o termo Functional Walking Skeleton criado por Alistair Cockburn. Nada mais do que uma pequena implementação do sistema que desempenha uma pequena função de ponta a ponta. É uma forma de POC (Proof of Concept) da arquitetura básica na qual não é necessário se preocupar com boas práticas de código, testes unitários e design.
Outro segredo da boa estimativa é MEDIR. Você conseguirá melhores estimativas se você tiver mais exemplos de quanto tempo as coisas similares levaram para serem construidas.
Algo que pode impactar bastante no custo é ignorar os riscos. Exponha os riscos no mapa.
A largura e a profundidade de um mapa típico dão uma idéia do tamanho do projeto. O número de caminhos através do mapa é um bom indicador de complexidade. Mas, uma vez que a falta de certeza e o risco não estão refletidos no mapa, então o mapa não descreve a quantidade real de trabalho (incluindo a aprendizagem) a ser feita.
Qualquer pessoa que seja obrigada a cumprir um prazo e aprender durante o caminho reconhece essa estratégia.
Use o pensamento iterativo para avaliar e fazer mudanças no que você já fez, avaliando o que foi feito e mudando que precisa. Mudanças no software que já foi feito muitas vezes é visto como uma falha. Mas todos sabemos que a mudança é um resultado necessário da aprendizagem.
Use o pensamento incremental para fazer mudanças. Primeiro crie uma simples versão das funcionalidades e vá adicionando mais funcionalidades. Se tudo der certo, o time vai construir algo diferente da versão inicial imaginada, algo melhor, trazendo os benefícios do aprendizado.
Não importa o quão pequeno seja o produto ou uma funcionalidade, corte o backlog em 3 grupos:
Foque nas funcionalidades essenciais ou nos passos do usuário que passam por todo o produto. Pule as coisas opcionais que talvez os usuários façam. Pule regras de negócios sofisticadas ou que você sabem que vai precisar implementar antes do lançamento. Construa apenas o suficiente para o produto funcionar de ponta a ponta.
Complete funcionalidades anteriores. Adicione coisas para suportar os passos opcionais que os usuários podem executar. Implemente as regras comerciais difíceis. Agora você pode testar de ponta a ponta coisas como desempenho, escalabilidade, usabilidade e segurança. Essas são questões de qualidades difíceis de serem percebidas mas que devem ser testadas constantementes.
Refine sua versão. Torne ela mais sexy e eficiente de usar. Como você pode usá-lo agora com dados reais e em escala, aqui é onde você encontrará oportunidades de melhoria que eram difíceis de ver em um protótipo. É aqui que você consiguirá obter feedbacks dos usuários.
Se você descobriu o que acredita ser viável para uma primeira release, trabalhe junto com o time para decidir o que da primeira release pública vai entrar nos grupos Bicicleta, Moto e Carro. O time que cria o produto é o melhor para identificar onde estão os riscos e as oportunidades de aprendizado. As pessoas sentirão um forte sentimento de ownership sobre o plano que criaram juntas.
Se você pensa que criar um story map é difícil, complicado ou místico, está enganado.
Vamos usar um exemplo do que você faz quando acorda até ir para o trabalho. Escreva os passos em um sticker note, um ao lado do outro. Ex.: o despertador toca, desligo despertador, vou ao banheiro, tomo banho, visto uma roupa e entro no carro.
Toda frase curta que começa com verbo são tarefas para um objetivo. Ex.: tomar banho, escovar dentes.
User Tasks são as tarefas que pessoas fazem no nosso software para alcançar um objetivo, o bloco básico para construir um story map. Elas são o conceito mais importante para construir um bom story map. Você vai perceber que a maioria dos sticky notes sobre o que as pessoas fazem utilizando o software começam com verbos.
Tarefas são como pedras. Se você bater forte com um martelo numa grande pedra, ela se quebra em pedaços menores. Esses pedaços ainda são pedras. É a mesma coisa com as tarefas. Agora eu não sei quando uma pedra é grande o suficiente para ser chamado de pedregulho ou pequena o suficiente para ser chamado de pedrinha, mas há uma ótima maneira de contar uma grande tarefa a partir de uma pequena tarefa.
Podemos utilizar uma metáfora de altitude onde o nível do mar fica no meio e qualquer outra coisa fica acima ou abaixo. Uma tarefa no nível do mar é quando esperamos completar antes de começar outra. Por exemplo, a tarefa "tomar banho" é uma tarefa de nível do mar porque não é algo que você possa dizer: "Acho que vou tomar um café e depois eu termino meu banho". Esse tipo de tarefa é chamada de functional-level tasks e podemos representá-las no mapa como uma pequena onda no oceano.
Tarefas como "tomar banho" podem ser quebradas em subtarefas como "ajustar temperatura da água" e "lavar os cabelos". Podemos representá-las como peixes porque elas estão abaixo do nível do mar.
Finalmente, podemos agrupar um monte de tarefas em uma tarefa de nível de resumo. Tomar um banho, barbear, escovar os dentes e todas as outras coisas que você faz na parte da manhã, depois de sair da cama, podem ser agrupadas em uma tarefa de resumo, por exemlo, "se limpar".
Use o conceito de goal-level para ajudá-lo a agrupar pequenas tarefas ou decompor tarefas grandes.
Organize da esquerda para a direita, sendo do lado esquerdo o que você precisa fazer e do direito o que pode deixar para depois. Tente contar uma estória seguindo uma sequência. Os mapas são organizados de esquerda para a direita usando um fluxo de narrativa: a ordem na qual você conta a história.
Pense no cenário perfeito e no que pode dar errado. Pense em outros cenários que podem acontecer se houver alguma ação diferente.
Detalhes, alternativas, variações e exceções devem ser adicionadas no mapa.
Adicione as stories alternativas ou detalhes abaixo da respectiva estória principal em um fluxo de cima para baixo.
Você pode contar a história do dia típico, a estória do dia fabuloso e a estória que tem uma ou duas emergências, sempre usando diferentes sticky notes de acordo como você conversa, da esquerda para a direita. Tente usar algumas outras conjunções para colocar suas tarefas juntas. Você pode dizer: "Normalmente faço isso, mas às vezes eu faço isso" ou "eu faço isso, ou isso, e depois isso".
Até agora seu mapa deve está muito comprido, parecendo uma coluna e costelas de um animal.
Se olhar direito vai perceber que há alguns conjuntos de stories que parecem seguir juntas para um objetivo maior. Acima de cada grupo de stories similares, insira sticky notes coloridos contendo frases curtas iniciando com verbos para refinar as tarefas da story. Esses sticky notes com tarefas de alto nível são chamados de atividades. Elas organizam um monte de tarefas realizadas por pessoas semelhantes em momentos semelhantes, para alcançar um objetivo específico. Quando você lê as atividades no topo do mapa, elas também estão em um fluxo narrativo.
A linha de sticky notes é o backbone do mapa. Se você obteve um mapa com muitos sticky notes e você quer descreve-lo, uma boa maneira de começar é contar uma estória de alto nível. Basta ler o backbone do mapa, com a conjunção "... e depois..." entre cada atividade.
As atividades adicionam tarefas direcionadas à um objetivo comum e junto com as tarefas de alto nível formam o backbone de um story map. Não há uma linguagem comum para descrever o que as tarefas fazem. Melhor utilizar o termo que o cliente utiliza.
Trace uma linha no mapa abaixo do objetivo e mova para acima da linha todas as stories e atividades relevantes para alcançar o objetivo.
São mapas criados para entender melhor os usuários. Você pode utilizá-lo para entender no momento atual:
- Dores, coisas que não funcionam, partes das pessoas odeiam
- Alegrias ou recompensas, as coisas divertidas, as coisas que fazem valer a pena
- Perguntas, por que as pessoas fazem isso? O que está acontecendo quando eles fazem?
- Idéias, coisas que as pessoas poderiam fazer, ou que pudéssemos construir para resolver as dores ou tornar a vida dos usuários melhor
- As tarefas são frases verbais curtas que descrevem o que as pessoas fazem.
- Tarefas têm diferentes níveis de objetivo.
- As tarefas em um mapa são organizadas em um fluxo narrativo de esquerda para a direita.
- A profundidade de um mapa contém variações e tarefas alternativas.
- As tarefas são organizadas por atividades no topo do mapa.
- As atividades formam o backbone do mapa.
- Você pode cortar o mapa para identificar as tarefas que você precisará para alcançar um resultado específico.
- Enquadre o problema. Para quem é, e por que estamos construindo isso?
- Mapeie o quadro geral. Vá 1 Km de largura e 1 cm de profundidade. Tente mapear o mundo como é hoje, incluindo dores e alegrias que seus usuários têm.
- Explore. Vá fundo e converse com outros tipos de usuários e pessoas, como eles fazem as coisas, e os tipos de coisas que podem dar errado. Faça esboços e protótipos, teste e refine idéias e soluções, alterando e refinando o mapa conforme o necessário.
- Faça um corte no mapa para uma estratégia de release. Lembre-se: sempre há muito para construir. Concentre-se no que você está tentando alcançar para o seu negócio e nas pessoas que seu produto irá servir. Corte o que não é necessário para revelar soluções mínimas.
- Faça um corte no mapa para uma estratégia de aprendizado. Você pode ter identificado o que pensa ser um MVP, mas lembre-se que ainda assim é uma hipótese que deve ser validada. Use o mapa e a discussão para ajudá-lo a encontrar seus maiores riscos. Corte o mapa em MVPs menores que você pode mostrar para alguns usuários para aprender o que é realmente valioso para eles.
- Faça um corte no mapa para uma estratégia de desenvolvimento. Se você cortou tudo o que não precisa entregar, ficará com o que precisa. Agora corte o MVP em partes menores sobre o que você gostaria de construir logo e outro corte sobre o que construir mais tarde. Concentre-se em construir coisas logo que o ajudem a aprender a detectar questões técnicas e riscos de desenvolvimento mais cedo.
Use imagens com palavras para construir o entendimento compartilhado. Não basta falar sobre o que construir: fale sobre quem e porquê o produto vai ser utilizado, assim você minimiza as entregas e maximiza os resultados.
A idéia original sobre stories foi criada em 2010 por Kent Beck. "Pessoas contam estórias legais sobre funcionalidades que elas gostam. Se elas podem contar a estória antes, por que não depois?".
Podemos ler o mesmo documento e ter um entendimento diferente dele. Documentos geralmente descrevem sobre o que precisa ser feito e não a razão.
A melhor documentação vem a partir da colaboração entre as pessoas com os problemas a serem resolvidos e as pessoas que podem implementar criar a solução.
Pessoas que começam a usar stories para desenvolvimento de software mas tem um modelo de processo tradicional na mente, tendem a focar na parte da escrita. Isso as deixam frustradas pois para a dinâmica funcionar bem todos precisam discutir juntos.
Ron Jeffries descreve melhor o processo utilizando os 3 Cs:
- Card: escreva o que você gostaria de ver no software.
- Conversação: todos juntos devem ter uma discussão rica sobre o que construir.
- Confirmação: todos juntos concordando quando o software está pronto. Se construímos o que concordamos, o que devemos verificar para saber que terminamos? A reposta para isso é uma lista de coisas a serem conferidas, conhecido como critérios de aceitação.
Conversar sobre stories é muito simples mas para muitas pessoas é estranho e desconfortável. Por isso elas acabam revertendo para uma conversa sobre requisitos, que é o tipo de conversa que elas estão acostumadas.
Quando Kent Back inventou a idéia de stories, ele nao usou o termo user stories, apenas stories. Com o tempo o prefixo user foi adicionado para lembrar de ter conversas a partir da perspectiva das pessoas fora do software.
É importante que o time que vai construir o produto participe das discussões para criar o story map. Sem eles, no momento de começar a construir o produto, o time vai precisar tirar dúvidas com frequência. Para tentar minimizar isso, foi criado um template seguindo a estrutura:
Como [tipo de usuário] Eu quero [ação] Para [realizar um objetivo]
Use um template simples para iniciar uma conversa. Mas escrever seguindo um template não significa que o que está escrito é uma story. O valor da story vem com o que se aprende quando ela é contada.
- Converse sobre o usuário. Seja específico, há vários tipos de usuários. Converse também sobre os tipos de usuários. Há diversos tipos de usuários usando as mesmas funcionalidades. Converse sobre as funcionalidades das diferentes perspectivas.
- Converse sobre o que. Fale sobre o que o produto deve fazer, discuta sobre componentes de UI e comportamentos na tela.
- Converse sobre o por que. Qual o motivo de fazer o produto, por que o usuario e o cliente se importam.
- Converse sobre fora do software. Onde as pessoas vão utiliza-lo, quando e com que frequência.
- Converse sobre as coisas darem erradas. O que acontece quando o sistema cai ou os usuários não conseguem utilizar alguma funcionalidade.
- Converse sobre dúvidas e hipóteses. Identifique as questões que devem ser respondidas antes de começar o desenvolvimento. Você realmente conhece o usuário? Os problemas são realmente problemas que devem ser resolvidos? Eles vão realmente utilizar nossa solução? Os riscos técnicos estão sendo levados em conta?
- Converse sobre melhores soluções. Qual solução é mais eficaz e econômica para construir?
- Converse sobre como. Como o produto vai funcionar?
Saiba como contribuir