Um backlog plano é uma lista ordenada por prioridade. Ele diz o que construir a seguir, mas não como as peças se encaixam, e facilita o lançamento de dez recursos polidos que não resultam em algo que o usuário possa concluir. Um mapa de histórias de usuário corrige isso ao dispor as histórias ao longo da jornada do usuário, permitindo que você veja o produto inteiro e corte um primeiro lançamento que funcione do início ao fim.
Este guia aborda como criar um mapa de histórias, como transformar sua fatia superior em um escopo de MVP, como verificar cada história com INVEST e os padrões de divisão que transformam histórias grandes em histórias do tamanho de um sprint. Se você precisa das bases primeiro, comece com como escrever user stories.
O que é um mapa de histórias de usuário
O mapeamento de histórias foi introduzido por Jeff Patton, primeiro em um artigo de 2005, “It's all in how you slice it”, e depois em sua publicação de 2008 The new user story backlog is a map, e mais tarde em seu livro User Story Mapping (O'Reilly, 2014). Veja também seus recursos de mapeamento de histórias e a entrada do glossário da Agile Alliance.
Um mapa tem duas direções:
- Da esquerda para a direita é a narrativa: as grandes atividades pelas quais o usuário passa, em ordem, e os passos dentro de cada uma. Esta linha superior é chamada de espinha dorsal.
- De cima para baixo é prioridade e detalhe: sob cada passo estão as histórias que o tornam possível, com as mais essenciais no topo e alternativas, casos de borda e desejos abaixo.
Linhas horizontais através do mapa então o dividem em fatias de lançamento. Tudo acima da primeira linha é o primeiro lançamento; ele deve cobrir cada atividade na espinha dorsal, por mais fino que seja.
Como criar um mapa de histórias em 6 passos
Você pode fazer isso em uma parede com post-its ou em uma lousa digital. Convide as pessoas que decidirão o escopo e as pessoas que o construirão: produto, design, pelo menos um desenvolvedor e, idealmente, alguém que fala com os clientes. Um primeiro mapa para um produto pequeno geralmente leva uma sessão de trabalho de algumas horas.
1. Enquadrar o problema
Escreva para quem o produto é, o problema que ele resolve e o resultado que lhe diria que o primeiro lançamento funcionou. Mantenha-o em três frases no topo do mapa. Cada corte posterior é julgado com base neste resultado.
2. Mapear a espinha dorsal
Pergunte “o que o usuário faz primeiro, e depois o quê?” e escreva cada atividade em um cartão, da esquerda para a direita. Use verbos: “Encontrar um passeador”, não “Buscar”. Depois, divida cada atividade em passos. Conte a história em voz alta enquanto avança; as lacunas ficam óbvias quando alguém diz “espera, como eles chegaram aqui?”
3. Explorar os detalhes
Sob cada passo, adicione as histórias que o fazem funcionar: opções, alternativas, casos de erro, necessidades de administração. Não filtre ainda. É aqui que o mapa se paga, porque as pessoas notam peças faltantes quando podem ver a jornada inteira de uma vez.
4. Encontrar o esqueleto andante
O esqueleto andante (um termo de Alistair Cockburn) é a versão mais fina do produto que funciona de ponta a ponta. Escolha a história sob cada passo que o usuário não pode fazer sem, e mova-a para o topo. Se algum passo não tiver nada essencial, pergunte se ele pertence à espinha dorsal.
5. Fatiar lançamentos
Desenhe linhas horizontais para agrupar histórias em lançamentos. Dê a cada fatia um nome que declare o resultado, como “Donos podem agendar e pagar por um passeio”, em vez de “Lançamento 1”. Cada fatia deve ser utilizável por si só e responder a uma pergunta que você tem sobre o produto.
6. Planejar a primeira fatia e manter o mapa vivo
Escreva critérios de aceitação para as histórias na primeira fatia (nosso modelo de história de usuário tem três formatos), verifique cada uma contra INVEST, divida as que são grandes demais e mova-as para o backlog do sprint. Mantenha o mapa visível e atualize-o após cada lançamento; é uma ferramenta de planejamento, não uma saída de oficina única.
Exemplo: um mapa de histórias para um aplicativo de passeios com cães
Aqui está um mapa condensado para um marketplace que conecta donos de cães a passeadores locais. As colunas são a espinha dorsal; cada linha é uma fatia de lançamento.
| Fatia | Cadastro | Encontrar um passeador | Agendar um passeio | Pagar | Durante o passeio | Após o passeio |
|---|---|---|---|---|---|---|
| Esqueleto funcional (MVP) | Cadastrar com e-mail; adicionar um cachorro | Ver uma lista de passeadores aprovados perto de um CEP | Solicitar um horário; o passeador aceita por e-mail | Pagar com cartão no momento da reserva | O passeador marca o início e o fim da caminhada | O dono recebe uma mensagem de resumo |
| Lançamento 2 | Entrar com Google ou Apple; vários cachorros | Filtrar por preço e disponibilidade; perfis de passeadores com fotos | Aceitar e recusar dentro do app; lembretes | Cartões salvos; reembolso automático em caso de cancelamento | Localização em tempo real no mapa | Avaliações e comentários |
| Mais tarde | Códigos de indicação | Passeadores favoritos | Reservas semanais recorrentes | Assinaturas e gorjetas | Atualizações com fotos durante a caminhada | Reagendar com um toque |
Observe o que o esqueleto funcional omite: não há rastreamento em tempo real, não há avaliações, não há mensagens dentro do app e a aprovação dos passeadores é feita manualmente. Mas o dono ainda pode ir do cadastro a uma caminhada concluída e paga, o que é suficiente para testar se as pessoas reservarão um estranho para passear com seu cachorro.
Como o mapa se transforma no escopo do MVP
A fatia superior de um bom mapa é o escopo do seu MVP. Use estas verificações antes de se comprometer com ela:
- Cobre todas as atividades da espinha dorsal. Um produto que permite reservar, mas não pagar, não é um MVP; é meio demo.
- Atende a um usuário principal e a uma jornada principal. Papéis secundários (administradores, parceiros) recebem o mínimo necessário para manter a jornada em funcionamento, muitas vezes uma planilha ou uma etapa manual.
- Testa uma suposição específica. Escreva a pergunta que a fatia responde ao lado dela, por exemplo “Os donos pagarão antes de conhecer o passeador?”
- Trabalho manual nos bastidores é permitido. Aprovar passeadores manualmente ou enviar resumos por conta própria é aceitável para os primeiros usuários e indica o que vale a pena automatizar.
- Cabe no seu orçamento e prazo. Se não couber, corte histórias dentro de cada coluna (divida-as, usando os padrões abaixo) em vez de descartar colunas inteiras.
Para fundadores sem um cofundador técnico, o mapa também é o documento mais útil que você pode entregar a uma equipe de desenvolvimento: ele mostra o produto inteiro, o primeiro lançamento e o raciocínio por trás do corte, em uma página. Nosso guia sobre construindo um MVP como fundador não técnico cobre o que fazer com ele em seguida.
A lista de verificação INVEST
Uma vez que as histórias estejam no mapa, verifique cada uma na primeira fatia contra o INVEST, o acrônimo proposto por Bill Wake em 2003 em INVEST em boas histórias e tarefas SMART.
| Letra | Significado | Pergunta a fazer | Se não passar |
|---|---|---|---|
| I | Independente | Podemos construir e lançar isso sem esperar por outra história? | Combine histórias fortemente acopladas ou divida de outra forma para que cada uma entregue valor por si só |
| N | Negociável | A solução ainda está aberta para discussão? | Remova detalhes de implementação da história; mantenha-os nas notas |
| V | Valioso | Um usuário ou o negócio notaria se isso fosse lançado? | Mergulhe tarefas técnicas na história que elas atendem |
| E | Estimável | A equipe sabe o suficiente para dimensioná-la? | Execute um spike com tempo limitado ou faça as perguntas que estão bloqueando a estimativa |
| S | Pequeno | Ela cabe confortavelmente em um sprint? | Divida-a com um dos padrões abaixo |
| T | Testável | Podemos escrever critérios de aceite que passam ou falham? | Substitua palavras vagas (“rápido”, “fácil”) por resultados observáveis |
A Independência é o critério mais difícil de atender plenamente, e está tudo bem tratá-lo como uma meta em vez de uma regra. Pequeno e Testável são os que valem a pena ser estritos.
Como dividir histórias de usuário
Divida as histórias verticalmente: cada parte ainda deve entregar algo que o usuário possa ver, através de todas as camadas do sistema. Dividir por camada (“construir o banco de dados”, “construir a API”, “construir a tela”) produz peças que não entregam nada até que todas as três estejam concluídas, o que anula o propósito. Esses padrões, reunidos no Guia Humanizing Work para dividir histórias de usuário de Richard Lawrence e Peter Green, cobrem a maioria dos casos.
Etapas do fluxo de trabalho
Divida um processo de várias etapas em suas etapas, ou construa primeiro a versão simples de ponta a ponta e adicione etapas depois. “Agendar um passeio” se torna: solicitar um horário; o passeador aceita; o dono recebe uma confirmação. Depois: o passeador propõe um horário diferente.
Variações de regra de negócio
Se uma história tiver várias regras, lance primeiro a mais comum. “Reembolsos de cancelamento” se torna: reembolso total se cancelado 24 horas antes; reembolso parcial dentro de 24 horas; sem reembolso após o início do passeio.
Variações de dados
Comece com um tipo de dado e adicione os outros. “Buscar por localização” se torna: buscar por CEP; depois por localização atual; depois desenhando uma área no mapa.
Caminho feliz primeiro, caminhos infelizes depois
Construa o caminho principal de sucesso, depois trate falhas como histórias separadas, ordenadas por frequência e pelo dano que causam. “Pagar com cartão” se torna: pagamento bem-sucedido; cartão recusado; provedor de pagamento indisponível.
Operações
“Gerenciar cães” esconde criar, visualizar, editar e excluir. Muitas vezes, apenas criar e visualizar são necessários para o primeiro lançamento.
Variações de interface ou plataforma
Lance em uma plataforma ou método de entrada primeiro. Web antes de mobile, ou inglês antes de outros idiomas, se seus primeiros usuários permitirem.
Versão simples primeiro, adiar desempenho
Faça funcionar, depois faça rápido. Uma lista de passeadores que carrega em três segundos para 50 passeadores é aceitável para uma cidade piloto; otimize quando os números justificarem, como uma história própria.
Spike
Quando uma história não pode ser estimada devido a um desconhecido (“podemos obter localização ao vivo em segundo plano em ambas as plataformas de celular?”), separe uma investigação curta e com tempo limitado. A saída do spike é conhecimento e uma história melhor dimensionada, não funcionalidade lançada.
SPIDR: uma versão curta para lembrar
Mike Cohn agrupa as principais técnicas de divisão sob o acrônimo SPIDR: Spikes, Paths, Interfaces, Data e Rules (Cinco formas simples, mas poderosas, de dividir histórias de usuário). Se uma história for grande demais e você não tiver certeza de onde começar, percorra as cinco nessa ordem.
| Técnica | Dividir por | Exemplo |
|---|---|---|
| Spikes | Pesquise o desconhecido primeiro | Spike de dois dias sobre localização em segundo plano antes de estimar rastreamento ao vivo |
| Caminhos | Caminhos alternativos pela história | Pagar com cartão agora; pagar com carteira depois |
| Interfaces | Tipo de dispositivo, navegador ou interface | Reserva do proprietário na web primeiro, aplicativo móvel em segundo |
| Dados | Tipos ou faixas de dados | Um cão por reserva primeiro; vários cães depois |
| Regras | Regras de negócio, relaxadas no início | Sem regras de cancelamento no piloto; política de reembolso como uma história própria |
Erros comuns no mapeamento de histórias
- Mapear recursos em vez de atividades do usuário. Uma espinha dorsal de “Login, Painel, Configurações” descreve telas, não uma jornada.
- Construir a primeira fatia com apenas uma coluna de profundidade. Refinar o cadastro antes que a reserva exista deixa você sem nada para testar.
- Deixar o mapa ficar muito detalhado. Se você está escrevendo critérios de aceite na parede, você já saiu do mapeamento para o refinamento.
- Mapear sem os desenvolvedores na sala. Fatias desenhadas sem eles frequentemente escondem histórias caras no topo.
- Tratar o mapa como finalizado. Após cada lançamento, transfira o que aprendeu para o mapa e recorte a próxima fatia.
Para histórias bem formadas que você pode adaptar para o seu próprio mapa, veja nosso exemplos de histórias de usuário.
Ferramentas para mapeamento de histórias
Uma parede e post-its ainda funcionam melhor para a primeira sessão com todos em uma sala. Para equipes remotas, quadros brancos gerais como Miro e FigJam têm modelos de mapa de histórias, e ferramentas dedicadas como StoriesOnBoard sincronizam mapas com rastreadores de backlog. Jira e rastreadores semelhantes podem mostrar histórias agrupadas por épico, o que fornece a espinha dorsal, mas geralmente você precisa de um plugin ou de um quadro branco para ver as fatias de lançamento. Escolha a ferramenta que sua equipe manterá aberta; um mapa que ninguém atualiza deixa de ser útil em um ou dois sprints.
Perguntas frequentes
O que é mapeamento de histórias de usuário?
Uma técnica, introduzida por Jeff Patton, para organizar histórias de usuário ao longo da jornada que o usuário percorre (a espinha dorsal, da esquerda para a direita) e por prioridade (de cima para baixo). Linhas horizontais dividem o mapa em fatias de lançamento, para que a equipe possa planejar lançamentos que funcionam de ponta a ponta.
Qual é a diferença entre um mapa de histórias e um backlog de produto?
Um backlog é uma lista única ordenada por prioridade. Um mapa de histórias mostra as mesmas histórias em duas dimensões, por atividade do usuário e por prioridade, para que você possa ver como elas se encaixam e se um lançamento cobre toda a jornada.
O que é um esqueleto de caminhada?
A versão mais fina de um produto que funciona do início ao fim, com uma história essencial sob cada etapa da jornada. O termo vem de Alistair Cockburn; em um mapa de histórias, geralmente é a primeira fatia de lançamento.
O que significa INVEST?
Independente, Negociável, Valioso, Estimável, Pequeno e Testável. Bill Wake propôs isso em 2003 como uma lista de verificação para boas histórias de usuário.
Quão pequena deve ser uma história de usuário?
Pequena o suficiente para a equipe concluir, testar e demonstrar dentro de um sprint, e idealmente em poucos dias. Se uma história regularmente leva um sprint inteiro, divida-a.
O que é SPIDR?
Um conjunto de cinco técnicas de divisão de histórias descritas por Mike Cohn: Spikes, Paths, Interfaces, Data e Rules.
Quem deve participar de uma sessão de mapeamento de histórias?
As pessoas que decidem o escopo e as pessoas que vão construí-lo: product owner ou fundador, designer, pelo menos um desenvolvedor e, idealmente, alguém que fala com clientes, como suporte ou vendas.
Tem um mapa, ou apenas uma ideia, e precisa que a primeira fatia seja construída? Podemos ajudar você a definir um escopo de MVP que funcione de ponta a ponta e lançá-lo em sprints curtos. Veja nossos planos de desenvolvimento mensais.