User Story Mapping: como mapear o backlog por jornadas
O User Story Mapping resolve um problema que todo time com backlog grande conhece: a lista plana. Duzentos itens ordenados um abaixo do outro mostram o que vem primeiro, mas escondem a pergunta mais importante, que é como as peças se juntam para alguém usar o produto. O time termina a Sprint com cinco histórias prontas e nenhuma jornada completa: o usuário consegue se cadastrar e escolher o produto, mas não consegue pagar.
O story mapping troca a lista por um mapa de duas dimensões. Na horizontal, a sequência de atividades que o usuário percorre. Na vertical, as histórias de cada atividade, das essenciais às opcionais. Com essa visão, o time consegue cortar o produto em fatias horizontais, cada uma atravessando a jornada inteira, em vez de construir uma atividade de cada vez.
Abaixo estão o que é a técnica, quando usar, o passo a passo para montar o mapa, um exemplo preenchido e como levar o resultado para o Product Backlog.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é User Story Mapping
A técnica foi difundida por Jeff Patton e descrita no livro User Story Mapping, publicado pela O'Reilly em 2014. Ela não faz parte do Guia do Scrum: é uma prática complementar, como várias das citadas no guia completo de métodos ágeis e Scrum. A ideia central do livro é que histórias de usuário servem para conversar, e que uma lista de histórias perde o contexto dessa conversa. O mapa devolve o contexto ao mostrar onde cada história se encaixa na experiência do usuário.
O mapa tem três camadas:
| Camada | O que representa | Exemplo (compra on-line) |
|---|---|---|
| Atividades | Grandes objetivos do usuário, na ordem em que acontecem | Encontrar produto, comprar, receber |
| Passos (ou tarefas do usuário) | O que o usuário faz dentro de cada atividade | Buscar, filtrar, comparar |
| Histórias e detalhes | Formas de atender a cada passo, das mais simples às mais completas | Busca por nome; busca com sugestão; busca por voz |
As duas primeiras camadas formam o backbone, a espinha dorsal do mapa. Lida da esquerda para a direita, ela conta a história completa do uso do produto. Abaixo dela, as histórias ficam empilhadas por importância: quanto mais alto, mais essencial.
Para quem precisa rever a diferença entre épico, história e tarefa antes de montar o mapa, o artigo sobre épico, história de usuário e tarefa traz exemplos de cada nível.
Quando usar story mapping
A técnica rende mais em quatro situações:
- Início de produto ou de uma grande funcionalidade, quando o time precisa entender o todo antes de detalhar.
- Backlog grande e confuso, em que ninguém consegue explicar como os itens se relacionam.
- Definição do primeiro lançamento, para encontrar o menor conjunto que entrega uma jornada de ponta a ponta.
- Alinhamento com partes interessadas, porque o mapa é visual e fácil de discutir com quem não conhece o backlog.
Ela rende pouco em trabalho sem jornada de usuário clara, como correções de defeitos, sustentação de sistemas ou demandas técnicas isoladas. Nesses casos, uma lista ordenada ou um quadro Kanban resolvem melhor.
Como fazer User Story Mapping: passo a passo
- Defina para quem e para quê. Escolha um tipo de usuário e o objetivo dele. Se houver vários perfis muito diferentes, comece pelo principal e faça mapas separados depois.
- Reúna as pessoas certas. Product Owner, alguns Developers, alguém que conheça bem o usuário (atendimento, comercial, área de negócio). Entre quatro e oito pessoas funciona bem.
- Conte a história do uso. Peça ao grupo que descreva, em voz alta, o que o usuário faz do começo ao fim, em verbos: "procura", "escolhe", "agenda", "paga". Escreva cada passo num cartão.
- Organize os passos em atividades. Agrupe os passos que servem ao mesmo objetivo e dê um nome a cada grupo. Disponha as atividades da esquerda para a direita, na ordem da jornada. Esse é o backbone.
- Preencha as histórias abaixo de cada passo. Para cada passo, liste as formas de atendê-lo, das mais simples às mais sofisticadas, com as mais essenciais no alto.
- Explore exceções e alternativas. Pergunte o que acontece quando algo dá errado: o pagamento é recusado, o horário acaba, o usuário desiste no meio. Esses casos costumam gerar histórias esquecidas.
- Fatie as entregas. Trace linhas horizontais atravessando o mapa. A primeira fatia deve conter o mínimo de cada atividade para que a jornada funcione de ponta a ponta. As fatias seguintes enriquecem a experiência.
- Leve as fatias para o backlog. As histórias da primeira fatia vão para o topo do Product Backlog, e o mapa continua exposto para orientar as próximas decisões.
Uma sessão inicial costuma levar de duas a quatro horas para um produto de porte médio. O mapa não precisa ficar perfeito: ele é revisado à medida que o time aprende.
Exemplo de story map preenchido
O exemplo é ilustrativo. Uma rede de laboratórios quer um aplicativo para o paciente agendar exames, hoje feitos só por telefone. O usuário principal é o paciente com pedido médico em mãos.
Backbone (atividades e passos):
| Encontrar o exame | Agendar | Preparar-se | Fazer o exame | Receber o resultado |
|---|---|---|---|---|
| Informar o exame do pedido | Escolher unidade | Ver orientações de preparo | Fazer check-in | Ser avisado do resultado |
| Ver se o convênio cobre | Escolher data e horário | Receber lembrete | Ver o resultado no app |
Histórias por fatia:
| Fatia | Encontrar o exame | Agendar | Preparar-se | Fazer o exame | Receber o resultado |
|---|---|---|---|---|---|
| Primeira entrega | Digitar o nome do exame | Escolher unidade e horário em lista | Ver texto de preparo na confirmação | Apresentar o código do agendamento | Receber aviso por e-mail com link |
| Segunda entrega | Fotografar o pedido médico | Ver unidades no mapa | Lembrete um dia antes | Check-in pelo app na chegada | Ver resultado no app |
| Terceira entrega | Conferir cobertura do convênio | Reagendar e cancelar | Orientações por tipo de exame | Ver tempo de espera | Compartilhar resultado com o médico |
Repare que a primeira entrega é simples em cada coluna, mas permite que um paciente real faça o caminho inteiro. Se o time tivesse começado pela coluna "Encontrar o exame" completa, com foto do pedido e consulta ao convênio, levaria várias Sprints até alguém conseguir agendar.
Do mapa para o Product Backlog e as Sprints
O mapa não substitui o Product Backlog. Ele é uma visão de planejamento; o backlog continua sendo o artefato ordenado pelo Product Owner. A passagem de um para o outro funciona assim:
- As histórias da primeira fatia entram no topo do backlog e passam pelo refinamento do backlog antes da Sprint Planning: critérios de aceite, divisão e estimativa.
- Cada fatia pode virar uma meta. A primeira fatia do exemplo sugere uma Meta do Produto intermediária ("o paciente agenda e recebe o resultado sem telefonar") e uma sequência de Metas da Sprint.
- O mapa fica visível. Na Sprint Review, o time mostra no mapa o que foi entregue e discute com as partes interessadas se a fatia seguinte ainda é a certa.
Para entender como os diferentes tipos de backlog se relacionam, do produto à Sprint, veja o artigo sobre o que é backlog na metodologia ágil.
Story mapping remoto
Com time distribuído, o mapa vai para um quadro branco virtual. Algumas adaptações ajudam:
- prepare o quadro com as colunas de atividades vazias e cores combinadas (atividades, passos, histórias, dúvidas);
- divida o passo 5 em grupos menores, cada um com uma ou duas atividades, e depois reúna todos para revisar;
- faça pausas a cada 45 minutos, porque sessões longas em vídeo cansam mais do que presenciais;
- tire uma foto do mapa ao fim de cada sessão e registre as decisões de fatia.
Erros comuns no story mapping
- Mapear o sistema em vez do usuário. Atividades como "banco de dados" ou "tela de login" indicam que o mapa virou arquitetura. Use verbos do ponto de vista de quem usa.
- Primeira fatia grande demais. Se ela leva meses, não é a primeira fatia. Corte até que cada coluna tenha só o essencial.
- Mapa feito só pelo Product Owner. A técnica vale pela conversa; sem Developers e sem quem conhece o usuário, ela perde metade do valor.
- Mapa abandonado depois da primeira sessão. Ele precisa ser atualizado nas Reviews para continuar útil.
- Ignorar as exceções. Jornadas sem caminho de erro geram surpresas na homologação.
Por onde começar
Escolha a próxima funcionalidade grande do seu produto e reserve duas horas com o Product Owner, dois Developers e alguém do atendimento. Monte só o backbone e a primeira fatia: isso já basta para descobrir se o backlog atual entrega uma jornada completa. Se o seu trabalho é descobrir e priorizar produto, o curso de Gestão de Produto da Projeto Diário aprofunda as decisões sobre o que construir. Para dominar o ciclo do Scrum em que o mapa se encaixa, o curso Agile Scrum Foundation ensina papéis, eventos e artefatos em vídeo e prepara para o exame ASF.
