How to make a storymap. The basics for improving your backlog
Story mapping is a method for organising user stories, allowing a holistic view of the entire experience.
What is story mapping?
Story mapping is a method for organising user stories and allows you to create a more holistic view of the whole experience and process. And yes, it's also a method that can be proposed, used or moderated by designers.
I have used this method when working in product teams that mostly use the agile methodology and where maturity is low and they need some guidance.
This is because it forces and educates teams to write user stories in the right way, thinking more about users and less about the solution or technical limitations.
At the end of a Story Mapping you should have:
A holistic view of the product (backlog)
Features broken down into user stories
User stories broken down into technical tasks
Benefits
Story mapping can be used at various points in your project, such as during sprint planning. It should be a living document and changed as necessary.
Story mapping promotes product vision
Technical teams can have access to a vision of future work
Easier to map everything out (visually) and decide what the MVP will be for the first release.
Who should attend this workshop?
User Experience teams
Development teams
Product owner / manager
Scrum master
How to do story mapping
It's important to remember that story mapping should represent user tasks in a narrative way.
I would also remind you that a user story should represent an intention and objective rather than a functionality. We'll talk about user stories in another article...
Don't focus on technical complexity, but on the user's tasks.
It's important that the people involved know all the steps of the process so that they feel comfortable participating.
I've done this kind of workshop with programmers who start to panic if we don't talk about technical tasks or functionalities. In this case, tell them that we'll get to the technical tasks in due course, but that it's important to start with the tasks from the user's point of view.
First, let's define our persona and describe their tasks in their journey.
To make it easier, and if something has already been created, you can place that task as the centrepiece and complete the user tasks that take place before and after that moment.
Don't forget to write the tasks in narrative form and define the persona correctly.
Map tasks into activities
Now that you have the user's tasks, you can categorise or organise them into activities. In the future this could be the epics used in product management.
Create the user stories
You now have the basis of your map and we're going to start creating user tasks in more detail. Always from the user's point of view.
The best way to create user stories is to use the best-known model:
‘As [persona], I [want that]. [so that].’
This would work something like this: ‘As Sarah, I want to organise my work so that I feel more in control’
Define what is a priority and what will be in the next release
It should now be possible to prioritise user stories. You can help the Product Manager divide up the user stories by release, depending on the type of product management you have in place (continuous delivery, seasonal release, etc).
This mapping allows you to understand what will be delivered over time and the value you're bringing to each version of the product so that users can achieve their end goal.
Priorities can always be changed later, especially once you understand the technical difficulty of each one*. However, it is important to prioritise on the basis of user value.
Break down each user story into technical tasks
In the final phase of this workshop we should break down the user stories into technical tasks. These should allow the development teams to understand which tasks need to be done in order to support each user task. This also provides a better method for estimating and prioritising technical work according to its value to the user.
I've tried to summarise this activity as much as possible. You can find more information here:
O que é story mapping?
Story mapping é um método para organizar user stories e permite criar uma visão mais holística de toda a experiência e processo. E sim, também é um método que pode ser proposto, usado ou moderado por designers.
Tenho usado este método quando trabalho em equipas de produto que usam maioritariamente a metodologia agile e onde a maturidade é reduzida e precisam de alguma guidance.
Isto porque força e educa as equipas a escrever user stories da forma correta, pensando mais nos utilizadores e menos na solução ou limitações técnicas.
No final de um Story Mapping deverás ter:
Uma visão holística do produto (backlog)
Featurespartidas em user stories
User storiespartidas em tarefas técnicas
Benefícios
O Story mapping pode ser usado durante vários momentos do teu projeto, como por exemplo, durante o planeamento de sprints. Este deve ser um documento vivo e ser alterado conforme a necessidade.
O Story mapping promove a visão de produto
As equipas técnicas podem ter acesso a uma visão do trabalho futuro
Mais fácil de mapear tudo (visualmente) e decidir qual será o MVP para a primeira release.
Quem deve estar presente neste workshop?
Equipas de User Experience
Equipas de desenvolvimento
Product owner / manager
Scrum master
Como fazer um story mapping
É importante lembrar que Story mapping deve representar as tarefas do utilizador de forma narrativa.
Relembro também que uma user story deve representar uma intenção e objetivo em vez de representar uma funcionalidade. Falaremos de user stories noutro artigo…
Não te foques na complexidade técnica, mas sim nas tarefas do utilizador.
É importante que as pessoas envolvidas conheçam todos os passos do processo para que se sintam à vontade de participar.
Já fiz este tipo de workshops com programadores que começavam a entrar em pânico se não falássemos de tarefas técnicas ou funcionalidades. Neste caso, digam-lhes que a seu tempo vamos chegar às tarefas técnicas, mas que é importante começar pelas tarefas na ótica do utilizador.
Primeiro vamos definir a nossa persona e descrever as suas tarefas na sua jornada.
Para ser mais fácil, e caso já exista algo criado, podes colocar essa tarefa como ponto central e completar as tarefas do utilizador que acontecem anterior e posteriormente a esse momento.
Não esquecer de escrever as tarefas de forma narrativa e definir corretamente a persona.
Mapear as tarefas em atividades
Agora que já tens as tarefas do utilizador podes categorizar ou organizá-las em atividades. Futuramente isto podem ser os épicos usados em product management.
Criar as user stories
Neste momento tens a base do teu mapa e vamos começar a criar tarefas do utilizador em maior detalhe. Sempre na óptica do utilizador.
A melhor forma para criar user stories, é usar o modelo mais conhecido:
“Como [persona], eu [quero que]. [para que].”
Isto resultaria em algo assim: “Como Sarah, eu quero organizar o meu trabalho, para que me sinta com maior controlo”
Definir o que é prioridade e o que constará na próxima release
Agora deve ser possível prioiritzar as user stories. Podes ajudar o Product Manager a dividir as user stories por release, dependendo do tipo de gestão de produto que esteja em prática (entrega continua, release sazonal, etc).
Fazer este mapeamento permite entender o que será entregue ao longo do tempo e o valor que se está a aportar em cada versão do produto para que os utilizadores possam atingir o seu objetivo final.
As prioridades podem ser sempre alteradas mais tarde, sobretudo depois de entender a dificuldade técnica de cada uma delas*.* No entanto é importante priorizar com base no valor para o utilizador.
Partir cada user story em tarefas técnicas
Na fase final deste workshop devemos partir as user stories em tarefas técnicas. Elas devem permitir que as equipas de desenvolvimento entendam quais são as tarefas que têm que ser feitas, de forma a suportar cada tarefa do utilizador. Esta forma também permite um melhor método para estimar e priorizar o trabalho técnico de acordo com o valor para o utilizador.
Obrigado por leres a UX Snack Newsletter. Subscreve para receberes novos artigos e suportares o meu trabalho!
Tentei resumir ao máximo esta atividade. Podem encontrar mais informação aqui: