As a QA analyst, I have an intimate understanding of the things that we build. I don’t necessarily need to understand the code, which frameworks we need to use, or what web services need to be built — although I like to know these things. What is most important is that I understand the vision our client has for their website or web application project, because much of what I do involves putting myself in their shoes.
This, however, isn’t solely my job — I like to think of it as the responsibility of our entire project team. User story mapping is a technique that has helped our team achieve a shared understanding of our clients’ product vision.
At its core, user story mapping helps drive conversations in the form of stories, where the collection of these stories come together as a complete picture of the product we need to build. All you need are sticky notes and Sharpies. (Different colours of sticky notes help!)
The following is a quick rundown on how to conduct your own user story mapping session.
Where did user story mapping come from?
User story mapping is a technique developed by Jeff Patton. He’s a well known agile coach who’s dedicated to holistic design and development of software. I highly recommend you pick up his book, User Story Mapping: Discover the Whole Story, Build the Right Product. It’s a really quick read that I find myself going back to for reference often.
If you read Jeff’s book you’ll find an emphasis on the importance of telling stories, and more importantly, telling the whole story.
By the end of a user story mapping exercise you will have had conversations about every feature of your product, and you will be able to see the landscape of the entire product you’re building. I think these are the best reasons for you to consider using user story mapping on your next project.
How does user story mapping work?
Get people working on the project involved
Of course you want to invite the project team to participate in the exercise! No brainer, right? You would be amazed at how challenging this can be in a dynamic workplace where you and your colleagues have competing priorities.
Demand that your whole project team be present, because they need participate in order to have the conversations necessary to gain a contextual understanding of what problems need to be solved. Don’t be dissuaded by people who claim these meetings are too expensive! It is way more costly if your team doesn’t have a shared vision.
Some of the people you should consider inviting include a UX designer, developer, business and/or QA analysts, and most importantly, the people who possess the vision of the product. They will contribute different perspectives and angles to the problem you are trying to solve. One person can’t possibly know it all!
Who are the different people using the product?
Start things off by talking about the different people who will use the application. You can create simple personas and write down information that helps you understand what each person wants to achieve from using the software.
Talk about about how the product works
Have your client walk you through the product vision from the beginning, as if the product has already been built.
Identify the activities and steps within each activity
Frame the discussion around a particular user and the activities that person sees on a page. Write down the big activities, followed by things you can do within each activity (steps, processes, etc.).
Write down the details within each step
As the client walks you through the user experience of each step, add details in the form of stories that include a title, who the story is about, what that person wants and why.
For example, under the “View purchase history,” you may have a story that talks about displaying a past invoice:
Title: Download an invoice
Who: As a customer
What: I want to download a PDF invoice for a past purchase
Why: So I can print it for my records
During your conversation, ask questions and explore the details of the story.
- Should the purchase history be presented in a list?
- How should the list be sorted? Most recent?
- Is there an invoice number?
- How should dates be displayed?
- How do we treat different currencies?
- What should the customer see if he doesn’t have any past invoices?
To help drive a shared understanding, have UX team members sketch screens: pictures always do wonders to solidify ideas and concepts.
PRO TIP: Write down as many details as you can, regardless of how insignificant it might seem. Those details help give context to the conversations you are having around the stories you’ve created.
Organize stories into releases
Once you’ve have your activities, steps and stories, figure out what needs to be done first and which stories can be done later.
Do this by creating cross-sections across all the stories. In Jeff Patton’s book, he suggests basing releases on business outcomes: “Focus on outcomes — what users need to do and see when the system comes out — and slice out releases that will get you those outcomes.”
- Release 1: For an internal stakeholders to review
- Release 2: For initial public release
- Release 3: Nice to have features we can roll out after the initial public release
Now that you have created the releases, ask your client to place the stories into each release. Be sure to keep the stories organized under each step (column) so that overall landscape of the product is maintained.
What happens next?
Chances are, you won’t have all the details you will need and that’s OK. The stories you created are reminders to have conversations with your team. If there isn’t enough detail your team will let you know.
The point is, you are talking about the stories you created, and these conversations are opportunities to ask more questions, iron out assumptions, and discuss issues that will help build a clearer story.
Instead of creating stories in an application right off the bat, I encourage you to create stories using physical sticky notes and Sharpies. I find that there is less overhead and distractions creating stories with sticky notes — you just pick up a Sharpie and start jotting down notes!
However, you’ll find it challenging to follow-up your story mapping discussion without transferring your stories to some sort of tool. I’ve been using StoriesOnBoard. It’s a web-based app that allows you to create story maps and share them with team members. It helps you continue the conversation and sets your team up to start estimating, prioritizing, and executing on the stories.
I should note that StoriesOnBoard is in beta, but it’s free — and there are plans to add some great features to help teams collaborate.
As much as today’s collaboration tools help bring people together, nothing beats collaborating with people in person, using some sticky notes and Sharpies. User story mapping is really about having conversations; its fun when you can get on the same page and understand where the other person is coming from.
Do you have some user story mapping experiences you would like to share or other successful approaches you’ve used to collaborate? Share them in the comments or send me an email.