O framework de priorização: Mapeamento de Histórias

O mapeamento de histórias é um framework para organizar histórias de usuários para criar uma visão mais holística de como elas se encaixam na experiência geral do usuário. Organizados em um eixo horizontal, as etapas fundamentais da jornada do cliente (às vezes chamadas de “epicos”) são organizadas em ordem cronológica com base em quando um usuário executaria a tarefa específica em relação ao seu fluxo de trabalho geral com o produto.

Histórias de usuários individuais são organizadas embaixo das etapas maiores em que elas são agrupadas. Quando um mapa da história é concluído, você pode ver todas as maneiras pelas quais um usuário pode interagir com um produto em uma única visualização lógica, que progride da primeira interação à conclusão do objetivo geral do usuário.

O mapeamento de histórias geralmente é feito em uma parede (ou quadro) usando post-it. Geralmente, toda a equipe participa da identificação etapas fundamentais da jornada do usuário e, em seguida, atribui as histórias do usuário abaixo delas. Cada história é discutida, para que não haja dúvidas sobre o que realmente é, seu objetivo e como ela se encaixa no esquema geral das coisas.

Por que usar o mapeamento de histórias?

O mapeamento de histórias serve a alguns propósitos principais.

1. Mostra uma imagem completa de como um produto é usado, que geralmente é perdido durante o desenvolvimento da feature, pois a maioria das equipes se concentra em tarefas específicas e não na visão macro.
2. Pode identificar falhas na funcionalidade ou áreas em que se deve concentrar, pois pode destacar visualmente lacunas na experiência do usuário.
3. Pode ser uma excelente ferramenta para priorizar, tanto para um MVP (qual é o mínimo necessário para concluir o objetivo geral) quanto para lançamentos subsequentes (o que falta que deve / deve / pode estar lá).

É claro que o uso mais comum do mapeamento de histórias é utilizá-lo como uma alternativa ao gerenciamento “flat” do backlog, onde cada item é visualizado no vácuo, e não em um contexto visual geral. Preparar uma lista de pendências sem contexto pode funcionar, mas você perde a chance de visualizar a conexão e a importância de cada item na jornada geral.

Jeff Patton é creditado como o inventor do mapeamento de histórias e ele literalmente escreveu o livro (User Story Mapping). Esta invenção nasceu da constatação de que os documentos escritos são propensos a erros de interpretação, enquanto ter uma conversa real, era mais provável de levar a um entendimento e entrega de um produto que realmente atende às necessidades dos usuários pretendidos.

O objetivo do mapeamento de histórias é descobrir os detalhes que realmente são necessários para agregar valor ao cliente e evitar sessões de preparação que não envolvam totalmente o público e que acabam considerando cada item fora de contexto.

Embora Jeff tenha começado a introduzir o conceito em 2005, ele não foi oficialmente apelidado de “mapeamento de histórias” até 2008. Na década desde a sua introdução, ele foi adotado por muitos adeptos ágeis e incorporado em várias ferramentas para equipes de desenvolvimento de produtos.

A espinha dorsal do mapa da história é o conjunto principal de etapas pelas quais um usuário deve passar para atingir seu objetivo. Abaixo de cada etapa, estão os detalhes de cada uma das etapas maiores (epicos) (a etapa “grande” pode ser “checkout”, enquanto as etapas menores abaixo podem incluir a inserção / seleção do endereço de entrega, a seleção do método de entrega, a inserção / seleção do método de pagamento, a confirmação da remessa, o envio da remessa detalhes etc.).

O que realmente faz o mapeamento de histórias funcionar é sua dependência de recursos visuais como parte de um processo colaborativo interativo. Analisar um PowerPoint ou percorrer o JIRA é uma experiência passiva que, na melhor das hipóteses, inspirará uma forte reação das pessoas – “concordo”, “discordo”, “que está errado”, etc. -, mas raramente leva a uma conversa real.

No video abaixo, Jeff Patton da ProductPlan fala um pouco sobre como o Mapeamento de Historias funciona (Video em ingles)

O mapeamento de histórias é inclusivo e interativo

O mapeamento de histórias convida todos a “colocar a mão na massa” porque o mapa está sendo construído em tempo real, pessoalmente e em colaboração. À medida que as histórias são mapeadas para o fluxo de trabalho geral, há uma ampla oportunidade para desafiar, adicionar e editar, tudo relativo ao objetivo geral e sem focar em uma tarefa ou item distinto.

Ao trabalhar juntos no mapa da história, você cria um entendimento compartilhado e todos que saem da sessão estão na mesma página sobre o que é importante,por que é importante e como ele se encaixa no objetivo principal.

E como você não tem permissão para “seguir em frente” até que cada história do usuário (e como ela se encaixa na narrativa geral) seja totalmente compreendida por todos, você evitará inúmeras horas desperdiçadas de desenvolvedores e designers criando coisas que, na sua opinião, atendem aos objetivos ainda que aquém da realidade.

O melhor do mapeamento de histórias é que você pode começar a usá-lo durante qualquer fase do ciclo de vida do produto.

• Trabalhando em um MVP? Um mapa de história é uma ótima maneira de identificar as features mínimas necessária para testar seu conceito. Isso impedirá que você “esqueça” partes críticas da experiência do usuário que você poderia ter esquecido.
• Tentando descobrir como melhorar a versão 1.0? Um mapa de história pode exibir visualmente todos os aprimoramentos em potencial que você pode adicionar e pode ajudar sua equipe a ter conversas de qualidade sobre o que terá maior impacto sobre seus usuários.
• Gerenciando uma preocupação próspera e contínua? O mapeamento de histórias ajuda a domar a lista de pendências, dando contexto a cada item e forçando a priorização e o agrupamento com uma visão geral, além de destacar as lacunas que você nunca notou de outra forma.
• Ramificando com uma nova extensão de produto? Um mapa da história ilustrará o que você já tem e quais são as peças que faltam para que a nova funcionalidade funcione tão bem quanto a sua oferta atual.

Independentemente de seu produto ainda ser teórico ou estar em vigor há décadas, o mapeamento de histórias começa com personas – você deve saber quem usará seu produto e o que eles estão tentando realizar. Isso vai impulsionar tudo no futuro, pois você vai imaginar como eles usarão o produto antes mesmo de construí-lo.

E, à medida que seu seu produto amadurece, você precisará adicionar várias personas no mesmo mapa de histórias, pois diferentes usuários estão tentando realizar, diferentes coisas com seu produto. Se sua jornada não acomodar todos eles, esse processo identificará rapidamente as deficiências do seu produto nesses novos cenários.

Os mapas de histórias fornecem uma excelente porta de entrada para o processo de criar roadmaps. Com todos as features em potencial já mapeados e priorizados, você pode essencialmente agrupar as features de maior prioridade em lançamentos com base na largura de banda e na cadência de lançamentos de sua equipe.

Etapa 1 – Dimensionando as coisas

1. Preencha seu mapa da história com os itens menores organizados de cima para baixo com base na importância.
2. Em seguida, colabore com o desenvolvimento do produto, atribuindo a cada item um nível de esforço relativo (LOE). Pode ser horas, dias ou semanas, ou você pode utilizar algum outro sistema que dê ao líder do produto uma noção de quanto tempo cada coisa levará.

Esse também é o momento apropriado para agrupar todos os itens que podem se beneficiar da criação ao mesmo tempo. Dessa forma conseguimos aumentar a eficiência do desenvolvimento. Embora isso nem sempre determine que todos os itens relacionados sejam criados simultaneamente, é mais uma ferramenta para ajuda-los a evitar a priorização de features e depois deixa-las abandonadas.

Agora que você pode visualizar: o que é importante para cada etapa principal da coluna vertebral e o tamanho de um esforço que cada um exige, você precisará saber quanto trabalho real se encaixa em uma determinada versão. Por exemplo, você pode ter uma equipe de desenvolvimento de cinco pessoas e um ciclo de lançamento em que cada desenvolvedor tem 50 horas de tempo de desenvolvimento para novos recursos, te oferecendo 250 horas de trabalho.

Etapa 2 – Entendendo as coisas

Agora que você esta munido com o seu “custo” de desenvolvimento, a classificação de cada item e o custo de LOE de cada item, você tem informações suficientes para começar a inserir itens em diferentes releases (versões) no seu roadmap. Neste ponto, o mapa da história já fez grande parte do trabalho pesado, e agora você esta olhando de cima para baixo a partir da espinha dorsal para ver a quantidade de features cabe em cada versão.

O segredo, é saber decidir como alocar os diferentes itens em cada lançamentos. Você pode adotar uma abordagem igualitária em que cada etapa principal obtém um número relativamente igual de subitens a cada versão ou pode decidir se concentrar em uma (ou duas) etapas específicas para um determinado ciclo.

A última abordagem pode fazer sentido para um produto em sua infância (quando você está apenas tentando estabelecer uma quantidade minima de funcionalidades) ou quando um produto é bastante maduro e você está focado em melhorias iterativas ao longo do processo.

Mergulhar fundo em uma ou duas etapas específicas (como focar no “carrinho de compras”, pode ​​ser mais adequado para um produto que já está funcionando, mas que agora está pronto para aprimoramentos significativos e que pode se beneficiar do foco em uma area de cada vez.

Etapa 3 – Definindo resultados

Depois de decidir o que incluir em cada release, ele deve ser mapeado para um objetivo específico. Em resumo, o que esta versão deve realizar em termos de experiência do usuário? Por exemplo: pode ser a criação de contas sem atrito ou o recebimento de recomendações personalizadas de produtos.

Como todo sprint tem um resultado desejado, é muito mais fácil determinar se o sprint foi bem-sucedido. Por exemplo: se o objetivo da sprint era que os usuários possam escolher qual a cor que desejam para um widget, há uma medição binária de se esse resultado foi alcançado (ao inves de comemorar somente a finalização da roda de cores).

Etapa 4 – Iterando à vista de todos

Quando uma feature é muito grande para uma unica sprint, construa-a de maneira iterativa. Não construa features que só irão funcionar depois de várias sprints. Em vez disso:

1. crie primeiro as necessidades básicas.
2. desenvolva esse esqueleto durante cada sprint enquanto aprende com o uso no mundo real da primeira iteração.

Isso permite que você lance a funcionalidade no mercado o mais rapido possivel, e ao mesmo tempo, melhor seu design e execução baseada no feedback do usuário. Fazendo isso, você também vai reduzir os sprints que lançam somente a “fundação da feature”, mas não agregam valor real aos usuários finais.

Os mapas de histórias são trabalhos contínuos e estão sempre em andamento. À medida que as etapas são concluídas, novas são priorizadas e adicionadas. Enquanto isso, o feedback do usuário e a análise competitiva descobrem novos requisitos. Independentemente de você deixar o mapa de sua história atualizado / atualizá-lo ou recriá-lo periodicamente, a espinha dorsal e as principais etapas permanecem parte do processo.

A reavaliação regular do seu mapa de histórias é saudável e recomendada.

Você pode deixá-lo permanentemente na parede ou recriá-lo periodicamente, o que por si só pode ser um exercício perspicaz. Seja como for, a perspectiva obtida com o processo é inestimável, tanto na otimização da priorização de histórias de usuários, quanto nas revelações resultantes da discussão de cada história com toda a equipe.

O mapeamento de histórias é uma oportunidade para alcançar muitos objetivos com os quais os líderes de produtos frequentemente lutam.

• Você pode comunicar metas e objetivos gerais sem “dar palestras” para seus colegas de trabalho.
• Você pode criar um ambiente colaborativo que envolva todos para participar da estratégia de produto.
• Você pode explorar as idéias e conceitos em potencial que, de outra forma, não teriam visto a luz do dia.
• Você pode obter consenso e entendimento dos objetivos antes de sua equipe escrever uma única linha de código.

No entanto, o mapeamento de histórias não é rápido – você está mapeando TODAS as histórias de usuários – e precisará do espaço físico certo para fazê-lo. Talvez você precise convencer a gerência de que esse é um uso útil do tempo de todos.

Porém, no fim do dia, se o seu produto não estiver ajudando um cliente a concluir sua jornada, ele fará sua jornada em outro lugar ou simplesmente cancelará tudo. Um mapa da história alinha todos com esse objetivo e cria um ambiente rico em contexto, onde é fácil ver para onde as features devem seguir.

Se quiser saber mais sobre como você pode priorizar as features e requisitos de seu roadmap, mas tem duvidas de qual framework escolher, eu escrevi um ótimo artigo para ajuda-lo nessa escolha.

Esse artigo foi publicado anteriormente no site da ProductPlan – software para a criação de roadmaps