Scaling the User story map
Don't limit yourself with using the User story map just for one purpose and think outside the box.
In my previous posts I wrote about How to prepare for User story mapping workshop for the development and 6 tips for facilitation User story mapping workshop.
After I attended and facilitated several User story mapping sessions, I got the courage to experiment a bit, think outside the box and try to adjust the User story mapping for different cases.
Software development
Most common case for using User story map is in software development. It helps you to see the bigger picture of your product, to design the journey, to prioritise the user stories, to onboard all the team members and to have clear vision of the product which is understood by everyone. After I tried it once,
I found it awesome and I started to include it into every inception phase of development.
The only hard (and the most important) part of it is to remember that User story map is not something written in the stone, but living artefact which should trigger a discussion and evolve in time. So place it somewhere near the team and regularly work with it, reprioritise, add new tasks, remove some based new data, change the journey. Or move it on-line thus you can collaborate with everyone also remotely.
Small features
User story mapping does not have to represent only the whole product, but if you feel your product is too complex and you need to move forward, split it into smaller pieces.
Once I needed to convince the sponsors of the product that we can move forward without having clarity in everything. I arranged 2 days workshop where we did small user story map just for 2 goals and one persona. It worked, we showed that we can start by smaller pieces and define the rest later.
E-mailing strategy
If you are working on a product which requires some additional integrations or related communication, use the user story map as a framework. We did it with e-mail strategy. The user journey (backbone) has been defined but we had to tailor the e-mail strategy to it. We did it in regards with the journey — mapping the e-mails into user journey and then prioritized the e-mails which are must have, should have and nice to have.
Product Lessons learned
Last year I was working as a Product owner of web application for massive campaign, once the campaign was over, we struggled how to do the “product lessons learned”. User story mapping proved to be very handful ally again. We put the final user journey on the wall and then defined in each step of the journey what worked, what should be revised or what should be removed or completely changed. Then we prioritised the learnings based on impact of the change on the product. We took into consideration analytics data, usability testings, vision for next year, comments from business dept., legal dept. and our knowledge. Everything we gathered during the product development. It took us only 4 hours to map the whole product and learnings from discovery team on the wall and created solid base for further development.
Do you use User story map for any other purpose? Share your experience below and clap if you enjoyed the post :)
