Mapeamento de Histórias dos Usuários, ou User Story Mapping (USM) em inglês, é uma técnica popular criada por Jeff Patton para priorizar projetos ágeis de uma forma eficaz. A Lean Inception é um workshop colaborativo que estabelece o cenário para a criação de um produto enxuto com base na compreensão inicial para o produto viável mínimo, MVP.
Dependendo de como você olha para ele, USM pode ser conflitante ou ser um complemento à Lean Inception. Eu prefiro a segunda opção, complementando a Lean Inception com esta excelente técnica para organizar o backlog de trabalho.
A Lean Inception entraria em conflito com USM se uma técnica substituísse a outra, o que nós consideramos um erro perigoso. Primeiro, execute a Lean Inception para entender e organizar a evolução do produto através de MVP, o produto mínimo viável para validar algumas hipóteses de negócios. Em seguida, crie o USM para organizar o backlog de trabalho. O USM vai mostrar como cortar e construir o MVP com histórias de usuários.
“Na parte superior do mapa são grandes histórias. Eu chamo esses de atividades do usuário (aprendi esse termo com pessoas de UX como Larry Constantine e Don Norman). Uma atividade é uma espécie de grande coisa que as pessoas fazem.” Este é parte do texto original de Jeff no seu primeiro blog post sobre USM.
Tanto a Lean Inception quanto a USM são baseados nas User Journey, o passo a passo do usuário para atingir um objetivo.
Pessoas em primeiro lugar! Pense sobre o usuário e seu passo a passo para alcançar um objetivo. Na Lean Inception, isto é descrito na atividade Jornada do Usuário, a última atividade antes de se decidir sobre o MVP com as suas features.
A Lean Inception baseia-se no conceito de feature, a descrição de uma ação ou interação de um usuário com o produto. Por exemplo: impressão de um boleto, consultar a declaração detalhada, e convidar amigos do Facebook. A descrição de uma feature deve ser tão simples quanto possível.
O usuário está tentando fazer alguma coisa. O produto deve ter uma feature para isso. Que feature é essa?
Features são descritas em termos de características do produto, que são diferentes do que as atividades do usuário descritas nas jornadas do usuário. As jornadas são descritas sob a perspectiva dos passos e do objetivo do usuário. Design Thinking e UX reforçam que você não deve tentar adaptar o seu usuário para o seu produto, mas sim, adaptar o seu produto para os seus usuários.
Portanto, as jornadas do usuário são descritas no termo dos usuários e seus objetivos. Além disso, o seu passo a passo é amplamente descrito como atividades ou passos realizados pelo usuário. Alguns destes passos podem ter algo a ver com o produto que está sendo construído. Se for o caso, na Lean Inception, isso ficou esclarecido na atividade mapeando as features ás jornadas.
Diferentemente da Lean Inception, o USM vai em mais detalhes: ele mapeia o passo a passo para histórias de usuários. Então, se um passo poderia ter mais do que uma história, estas são mapeadas para tal passo.
A imagem apresentado é do blog post how to prioritize a User Story Map. Ela ilustra uma USM com seu passo a passo mapeada para histórias e releases.
Uma vez que o time entendeu e definiu o MVP na Lean Inception, é importante que a equipe descreva as features com um pouco mais de detalhe. Alguns times criam tarefas, outros criam histórias de usuário. Não é necessário criar todas as histórias para um dado produto logo no início de seu desenvolvimento, embora no contexto de MVP isto possa ser feito.
Da mesma maneira que uma arquitetura mínima viável é necessária para que o desenvolvimento do produto se inicie na direção correta, um conjunto inicial de histórias auxilia o time a implementar o que é importante, com a informação necessária para tal. O User Story Mapping pode ser realizado para um subconjunto de features, aquelas que serão implementadas primeiro. Conforme o desenvolvimento avança e o time começa a trabalhar em outras features, a mesma atividade pode ser repetida.
Ao realizar o USM, podem surgir histórias que levantem dúvida com relação à quando devem ser executadas. É possível que elas sejam parte do MVP, assim como podem ser parte de um release futuro. A decisão, no final das contas, é do time. Para o produto final, o resultado será o mesmo. Porém, o time deve lembrar que o objetivo do MVP é lançar um produto enxuto para medir resultados tão logo for possível, e se organizar de acordo.
[content_block id=3005 slug=inception-mvp-e-diretoaoponto]
