18 dicas para criar um User Story Map eficaz

User Story Mapping é um jeito de trabalhar com User Stories em processos ágeis. É para quebrar grandes histórias como você as conta. É sobre ter uma boa e velha conversa e organizar isso em forma de mapa. Conversando, é possível 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.

Eu expliquei em outro artigo sobre o que é User Story Mapping. Se você ainda não leu, clique aqui para ler o texto antes de prosseguir.
Confira as dicas para criar um User Story Map eficaz.

Dicas para criar um Story Map

1. Pare de tentar escrever documentos perfeitos

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 histórias de usuário é o entendimento compartilhado.
Histórias têm esse nome de acordo como elas devem ser utilizadas. Se você está criando user stories sem utilizar palavras e figuras, está fazendo isso errado. O importante não é a quantidade de material produzido mas sim o que elas nos fazem lembrar.

2. Converse sobre a coisa certa

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.
Pense em “como mudar o mundo quando estiver conversando e construindo o entendimento. Essa pensamento 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

3. Construa menos

Sempre existe mais a ser construído do que temos tempo, recursos e capacidade 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 que é entregue, maximize o resultado 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.

4. Pense, Escreva, Explique e Posicione

Escreva sua user story um passo de cada vez. Vamos usar um exemplo do que você faz quando acorda até ir para o trabalho. Escreva os passos em um sticky note, um ao lado do outro. Ex.: o despertador toca, desligo despertador, vou ao banheiro, tomo banho, visto uma roupa e entro no carro.

Tarefas são o que fazemos. 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.

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 histórias. Por fim, posicione seu sticky note em um espaço compartilhado onde todos possam ver e interagir.

5. Enquadre sua idéia

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?

Explore histórias de usuário alternativas. 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 user stories alternativas ou detalhes abaixo da respectiva história principal em um fluxo de cima para baixo.

6. Descreva os clientes e usuários

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 histórias.

7. Converse sobre as histórias de usuários

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 histó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 história sem dizer uma palavra. Mapear as histórias nos ajuda a encontrar buracos nos pensamentos.
Precisamos ter cuidado para não nos perder nos detalhes, especialmente quando quem está contando a história tem uma certa paixão por ela. Vá para o final da história antes de se perder nos detalhes.
Quando a história estiver grande, separe os passos dela em cards ao lado do card da história, da esquerda para direita.
Crie um card para a história, adicione os passos logo abaixo numa sequência 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 história.

8. Jogue o jogo do “e se”

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 por exemplo, 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.

9. Discuta sobre a oportunidade

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?

10. Valide o problema

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 você conversa com as pessoas, atente para quais podem ser bons candidatos a testar o novo software. Algumas empresas se referem à essas pessoas como customer development partners.

11. Prototipe para aprender

Imagine um monte de user 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.

12. Cuidado com o que as pessoas dizem que desejam

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.

13. Planeje para terminar a tempo

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 histórias 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.

14. Crie um backbone

Alguns conjuntos de user stories parecem seguir juntas para um objetivo maior. Acima de cada grupo de histórias similares, insira sticky notes coloridos contendo frases curtas iniciando com verbos para refinar as tarefas da user 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 histó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.

15. Refine o mapa

Trace uma linha no mapa abaixo do objetivo e mova para acima da linha todas as user stories e atividades relevantes para alcançar o objetivo.

Crie mapas de jornadas (Journey Maps). 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

16. Conte histórias melhores utilizando um template

Conversar sobre histórias é 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 histórias, ele não usou o termo user stories, apenas story. Com o tempo o prefixo user foi adicionado para lembrar de ter conversas a partir da perspectiva das pessoas fora do software, os usuários.
É 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 user story. O valor da story vem com o que se aprende quando ela é contada.

17. Utilize um checklist sobre o que realmente conversar

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?

18. Siga os seis passos para o User Story Mapping

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.

Conclusão

Estabelecer um entendimento correto sobre o que deve ser feito é essencial para o desenvolvimento de um produto com qualidade. User Story Mapping fornece uma dinâmica mais participativa e colaborativa do que reuniões de entendimento, que tendem a gerar ruídos na comunicação, principalmente quando muitas pessoas participam.
User Story Mapping é apenas uma das ferramentas de uma gestão voltada à eficácia. Entenda em 5 erros de gestão para entregar software medíocre.