Série: Agile Brazil 2010 | Parte 2 de 6 > Cobertura completa da primeira conferência nacional de métodos ágeis do Brasil
Voltei agora para o hotel, ainda com os post-its colados na mochila, carregando comigo não só anotações — mas uma maneira completamente diferente de pensar sobre produto. O workshop de David Hussman sobre User Story Mapping foi direto ao ponto: histórias, sim, mas com propósito.
Mapeando a Jornada do Usuário
Logo no início, Hussman nos dividiu em grupos diversos. Nada de times conhecidos ou zonas de conforto. A provocação era clara: construir um produto como se fôssemos uma equipe nova, lidando com uma ideia desde o zero. A ferramenta? Um story map.
Não era apenas uma parede cheia de post-its. Era um cenário vivo, onde as ações do usuário vinham antes dos épicos, as conversas antes dos entregáveis. Cada linha do mapa representava um fluxo real — o que o usuário tenta alcançar e em que ordem. Cada coluna, uma entrega potencial.
A clareza que isso gerava era impressionante. De repente, todos falávamos a mesma língua. O mapa nos forçava a deixar claro para quem estávamos construindo, por que e o que era essencial agora versus o que poderia vir depois.
Contar Histórias Importa
David fez questão de enfatizar: “Historinhas são melhores do que épicos.” E foi aí que caiu a ficha. Muitas vezes tentamos descrever funcionalidades grandes e genéricas demais. Mas ao mapear com histórias reais, entendemos melhor o uso, o valor, e a ordem lógica da entrega.
Em um dos exercícios, criamos um produto fictício de agendamento de consultas médicas. Começamos mapeando o fluxo do paciente, desde a pesquisa inicial até o recebimento da confirmação por SMS. Depois, dividimos essas etapas em pedaços menores: o que precisa existir no MVP? O que pode ser entregue na segunda iteração?
Esse exercício transformou como pensamos releases. Saímos da visão tradicional de backlog plano para um espaço tridimensional: fluxos, prioridades, dependências. Era como transformar um quebra-cabeça solto em uma estrada com placas.
Reduzindo a Ansiedade com Contexto
Um dos momentos mais marcantes foi quando Hussman nos desafiou a entregar apenas as histórias da primeira fileira horizontal do mapa. A princípio, a ansiedade bateu: e o resto? E se não der tempo depois?
Mas aí veio o ponto: “Reduzir escopo é aumentar foco.” Ao mapear antes, criamos segurança para descartar com consciência. Era diferente de simplesmente cortar: era entender o todo antes de decidir o que vem agora.
Esse tipo de alinhamento ajuda não só times técnicos, mas também negócios, produto, stakeholders. Em poucos minutos, conseguimos priorizar com base em fluxo de uso — não achismo. Algo que antes gerava debate sem fim virou colaboração produtiva.
Mão na Massa: Produto com Papel
Nada de slides infinitos. Hussman nos colocou para prototipar com papel e canetinhas. Criamos telas, fluxos, simulamos interações, tudo colado na parede junto ao mapa de histórias. Isso nos forçava a sair do mundo das ideias e entrar no mundo da experiência.
Foi nesse momento que entendi como story mapping acelera feedback. Ao colocar o fluxo do usuário visível, conseguimos identificar furos lógicos, telas redundantes, e até oportunidades de simplificação. Não foi só sobre priorizar — foi sobre refinar o entendimento compartilhado.
Além disso, ver outros grupos apresentarem suas ideias ampliou a criatividade coletiva. Ninguém saiu daquele workshop com uma só forma de mapear. Saímos com múltiplas inspirações, todas ancoradas na prática.
Story Mapping Não É Backlog — É Conversa
Uma das metáforas mais esclarecedoras que David trouxe — ecoando o que ele sempre repete em suas palestras — é que story maps não são apenas entregáveis, são conversas. Não são blueprints, são narrativas. Ele comparou backlogs tradicionais a listas de supermercado: itens empilhados verticalmente, desconectados do contexto. Um story map, em contraste, é um filme da experiência do seu produto.
Essa metáfora clicou para todo mundo. Paramos de tratar histórias como coisas isoladas para serem “feitas” e começamos a pensar em como os usuários se movem através de um sistema. Em vez de fatiar por tecnologia ou domínio, começamos a fatiar por jornada, por objetivos, por comportamento do mundo real.
Hussman reforçou isso várias vezes: “O mapa deve contar uma história que alguém quer ouvir.” Não é documentação, é alinhamento. Não é um plano, é uma visão compartilhada. E acima de tudo, deve evoluir conforme o produto — e as pessoas por trás dele — aprendem e crescem.
Um Convite à Maturidade
No encerramento, David nos lembrou que story maps não são uma fórmula. São uma forma de pensar. Um convite a tratar software como produto, não como funcionalidade. E mais do que isso, um lembrete de que nossas entregas só fazem sentido dentro de uma história maior.
Voltei para o hotel cansado, mas energizado. Com a cabeça cheia de ideias e um desejo sincero de aplicar. Não em outro workshop — mas no dia a dia. E, quem sabe, ajudar outros times a também enxergar o produto como uma jornada que vale a pena mapear com cuidado.
Obrigado David Hussman. Obrigado Agile Brazil. Que dia inspirador!
Navegação da Série Agile Brazil 2010:
- Anterior: Parte 1 - Workshop de XP na Prática
- Atual: Parte 2 - Story Mapping com David Hussman
- Próximo: Parte 3 - Minha Primeira Palestra Ágil
- Parte 4: Retrospectivas com Hugo Corbucci e Mariana Bravo
- Final: Parte 5 - Coaching de Guerrilha com Francisco Trindade