Multi-uses of User Story Mapping

User Story Mapping is normally a technique for Product Development, but you need not limit yourself for just one task or function.

Here we explore outside the box and look at applying User Story Mapping to product lessons, customer feedback, marketing strategies and even Christmas lists.

Software Development

User Story Mapping is most commonly used for software development. You are able to outline and see the bigger picture of your product. You can prioritise the user stories, identify the journey of your users and involve all team members to have a shared understanding.

It is not just a tool that you use to outline the project, it is a technique applied to every step of the way. You can change, adapt, reprioritise, add further tasks, scrap old tasks, and so on. While ideal to sit on a wall in the office with post-it notes one large company has a large 75″ display in the office with their FeatureMap on display for all offices and departments.

Moving to the digital has its benefits and allows all departments and those remote to the office to collaborate. In addition, you can allow your shareholders and in some cases, even your customers to get involved.

Movie Buddy first MVP

 

Product Lessons

Occasionally after a campaign, season, or annual review you look back at your product and hold a session of “product lessons learnt”:

  • Promote the recurrence of desirable outcomes
  • Preclude the recurrence of undesirable outcomes

Using User Story Mapping here can help you outline the user journey. Define each step which worked, and highlight what should be removed or revised.

Using layers you are able to prioritise your learnings by the impact on the user using analytics data, internal comments and observations, incident reports, and any further data or knowledge that can build a picture about your product and its presence.

Your goal is not to create a product but to highlight the users experience to learn.

 

Customer Feedback

Developing your map can involve the customer, allowing a public-facing map and open process you can get feedback direct from the customer.

Taking suggestions, feedback and ideas from customers is the golden goose.

We’ve all had the occasional user when you open up your ticket support system or email and in the inbox sits 10 emails all from the same person hammering feedback after feedback. These users are my favourite, and while initially a shock to the system, they offer the best value.

Taking all feedback to build your User Story Map and highlight the pain points reported.

Set columns for feedback, suggestions, bug reports and crashes.

Again, do not set this as a product development map but a feedback map and this can help you prioritise your next steps for development and also feed directly into Product Lessons.

 

Marketing and email strategy

When defining the user flow from a cold lead to a warm lead, add in tracking, and stages you’ll soon hit a complicated process. User Story Mapping, the super-hero of project management is here again.

Setting our a User Flow from cold lead, to warm lead, to sign-up, to conversion can all be done with a FeatureMap.

While mailing systems, like mail-chimp, can work exceptionally defining a campaign, following a user along a sales process (especially when plugged into marketing) is broader than MailChimp.

Below I have defined a map in FeatureMap to give you an example of a marketing process. Click the image to see the Map on FeatureMap.co:

A Marketing and Email example for a fictional product.

 

Christmas Lists

Happy Holidays to you all, and time for a bit of fun, but an entirely function one.

This year I was planning out what to buy my friends, family and fellow office workers and wanted a way to track what I had purchased. In some cases, I have commissioned artwork and needed picture frames and had presents that became a multi-stage process. I turned to User Story Mapping and whipped up a FeatureMap to help manage who was getting what!

Check out our Christmas Demo Map below:

Christmas Gifts Mapping – A fun way to use FeatureMap

Do you use User story mapping for any other purpose?

If you wish to try out FeatureMap.co it is free to use, and has a trial period upon signup of the premium features!

Customer Facing Story Mapping

A user story map is a method for visually covering a story, to help discussions, share understanding and can even be shared with customers.

When building your story map, you should include all the relevant people, regardless of position, in the team. Due to their different foundations and interests, they will all offer unique and valuable points of view. A User Story Map is used to map out what you, as developers or managers think about when it comes to the user’s experience.

One advanced tactic is to involve the customer with a customer facing Story Map.

Customers have probably seen roadmaps but to truly involve a customer a back-log will always show more detail, yet a Story Map can show your progress with a beautiful planned out snapshot.

Why use a customer facing Story Map?

Story Maps are for shared understanding and can share a clear overview of the whole product or project.

While you may not be able to share your post-it note maps very well, here at FeatureMap you can create a copy of your internal map and create a map for public facing, set it to public and share the link, such as this demo map:

The Moviebuddy Current Version

A tool such as FeatureMap, used to share your product design lends more value to the customer, as it is always online, available to view and offer feedback.

When should I use a customer facing story map?

When sharing story maps with customers, it is important to iterate that a story map is not a roadmap, it is a living, breathing, evolving workflow. One day you may have features and functions set for the next release and the very next day it could be bumped up, down or adjusted.

The value of such a map is measured not only in the transparency of your dev team and work, but the process of your dev team.

In one such instance, we saw a knowledgeable member of the public witness a planned feature who then recommended an alternative method and offered code, for free. Through sharing your Story Map the project was assisted by a passionate user.

Story Mapping evolves and changes. If your customers struggle with the methodology it is probably wise to have two maps, one for devs, and one for the customers. You can set one to private, for your team and shareholders who can work through it and have a public shared customer facing map which encourages feedback, and interaction. We advise experimenting with the entirely public facing single map first.

As such we advise involving a customer as soon as possible.

 

How to make the map public?

When on your FeatureMap, click the top right blue spanner icon:

Then below you’ll have your options pop up.

Here you can click “Make map public”.

Do note you can click this button again “Make map private” to remove your public access link.

Make your map public

 

Once public you’ll be able to share the URL and add this to your emails, webpage or direct as links.

To see an example demo map check here: https://www.featuremap.co/mp/FviDEf/moviebuddy

Due Dates, Estimations, Custom Fields

Creating your user story maps you will notice a few fields with due dates, importance, color, and custom fields which are default set to Estimation and Elapsed time.

Card view with further details about priority, deadlines and custom fields

The custom fields have the option to be aggregator fields and the numerical value will add up with other cards in the column, task, activity.

Here you can see that two cards have point values and cost values which are aggregated at the title card at the top:

 

Aggregation.

 

All these features and functions can help with building trust with your customers as you demonstrate transparency with your activities.

Take customer feedback and deliver extra value by integrating their suggestions, ideas and changes into cards, sprints and allow those customers to see their feedback, in real-time, get integrated into a product promoting customer loyalty.

JIRA Integration

FeatureMap offers JIRA integration.

You can sync your map with JIRA or import a snapshot of JIRA and edit it from that point.

With your User Story Map integrated with JIRA, you can sync your tasks and display a beautiful map of your backlog suited for your customer facing interaction.

You can get started with FeatureMap, and if you need more help or ideas, check out our 5 reasons to use User Story Mapping or a specific idea such as Feature Definition.

 

User Story Mapping – Steps to Success

User Story Mapping has been described as a niche tool to achieve much. Tools for product development, feature definition, version improvement and project management just to name a few.

In this case we are looking at the steps to success, utilising User Story Mapping methodology to help define your path. The first two steps instantly reward.

Firstly, planning the map rewards you a pathway to the point so that you can start writing user stories (a user story is a short description of something your customer will do when using your product).

Secondly, the end result is a visual chart showing the structure of your stories which gives you the steps to development.

Here is another way to approach User Story Mapping in three steps and this is a relatively quick way of getting to a point to start development work.

A finished User Story Map example.

Hosting your Story Mapping Session

Because User Story Mapping can come across as complex it is important that management of the session is approached with a framework. Needless to say that User Story Mapping can be a new tool for most people so outlining what it is all about and describing the process is important.

Start with tasks where the team thinks about the product, users, development and personas.

Step One

We start by brainstorming every task that users will want to address when using the product.

Silent Brainstorming. Task each participant to write down steps in your cards, every step will need to cover from the users first engagement to the conclusion of the users interaction.  Encourage the team to think of these as actions not features.

Top Tip: Writing them so they start with a verb is a good technique.

Encourage people to be creative and try to cover tasks and steps wide, but not deep. This part of User Story Mapping is about breadth not depth.

Start posting all cards and tasks in one large map. Thats fine, you’ll have duplicates, and these should sit beside each other on the line (not above or below). As you expand and learn you can easily drag and drop and delete if needed. The beauty of using digital software for large collaberation tasks such as this allows you and you and your team to easily edit, expand and develop your map.

This first line is the user tasks and they form the backbone of your story map.

Step Two

Then we organise these tasks into wider goals, and arrange them in order of completion.

These groups are known as “epics” or “activities”.

As facilitator you can walk along the line of tasks and ask where the team think the splits are between each group of tasks, and what each group should be called.

For example, if you were building an app for an app to arrange your movies you might group user tasks into epics like this:

Browse DVDs in collection – epic
View flat list of all DVDs – user task
View DVD cover thumbnails in results – user task
DVD Spec Call – user task

Step Three

We can then move into the Prioritisation exercise, further developing the user story map.

This is the stage where you start writing in the details, building up the tasks and redifining tasks. This may include adding tasks, merging tasks or seperating tasks.

It is important to detail the tasks enough to remember in the future.

After writing all the tasks, you should have a comprehensive map by this stage.

Task your team to go over each line (now defined as Epics/actitives) and ensure you have everything charted. This is where the User Story Map will become easier as you will now have a visual chart of a defined product. Here you can move to the next steps.

The Moviebuddy Current Version

Next Steps

Now you are ready to start prioritising the user stories on your map. You can start adapting and moving your tasks to sprints, also known as versions for your product.

You can check out the Movie Buddy Public Board here at FeatureMap.

You can do this all with Post-It notes with your in house team, or digitally using FeatureMap.co with your teams remotely and digitially.

Check out FeatureMap.co and sign up to try for free.

Intro to Story Mapping – Product Roadmap

A story user map can be used as a method for visually outlining your roadmap for your product.

We started this intro to story mapping with a basic run down and a simple exercise taking you through the morning tasks and making a map. Now we will look at how to outline your roadmap. Also don’t forget to check out some good practises in going from Idea to MVP.

If you are following the intro, you’ll have looked at how to outline your feature definition.

In our case study we are going to look at “Movie Buddy”. The Initial MVP was to generate an app which could be used to manage your DVD collection.

The first step is to identifiy your main goal, in this case it was “Manage my DVD Collection”

The next layer introducing tasks and we identified 4 main features.

  • Add a DVD to my collection
  • Browser DVDs in collection
  • Find a DVD in collection
  • View/Edit DVD info

From here we were able to fill in further details for each card in our first sprint.

Movie Buddy first MVP

The horizontal sprint delimits the first iteration we implemented from stories,  from ideas and how we chose to postpone features for a further iteration. We chose to implement the backbone for the main features and come back later to add details and fine-tunings.

From here we moved to the next step and that was expanding our features. You can see we have expanded a colum to the right (in green.)

We wanted to introduce a social element, a movie recommendation feature.

Now to add cards to this next sprint we needed a new horizontal layer, so adding sprint 2 (in purple) this allowed us to identify what improvements we wanted to add to our core back-bone features.

Expanding to sprint 2

You can see how with each new column of improvements and with each deployment of your application (or version) you can develop and expand your application using a simple user story map.

At a glance you can see which features are implemented, or which features are set to be implemented down the road.

In this example it was decided that the “Get Movies Recommendations” section was a good hit and so the idea was expanded. In addition our users wanted to expand our core backbone and introduce scanning of barcodes of DVD’s to identify it in our database.

We realised we could scan DVD’s by barcode, but taking photos of the cover would need extra work so we seperated the sprints, in addition we also wanted to improve our management of favourite directors/actors by allowing recommendations on directors but that would take time. This was also added to the later sprint.

Moving features down to another Sprint

This left us with our final idea and roadmap for the coming development cycles.

Notes

 

When designing a roadmap from your MVP it is okay to place down expanded ideas and the best features you can imagine. A user Story Map is designed to allow you to see the overall roadmap, the big picture, the ideal application.

Taking that application can then allow you and your team to arrange the features, arrange the sprints, split the application up to version and settle, together, with an ideal roadmap.

We have the MovieBuddy Map here if you want to see the completed MovieBuddy Map.

Intro to Story Mapping – Feature Definition

A story user map is a method for visually covering a story, to help discussions. The main purpose for making  a map is to build shared understanding for the individuals of a team.

We started this intro to story mapping with a basic run down and a simple exercise taking you through the morning tasks and making a map. Now we will look at how to define features in a product.

When you first start off it is best to have an idea of the ideal product, but have not yet started on your product roadmap. Instead start with the user’s normal workflow (minus the app or software) and figure out how to translate that flow into a product experience.

Below I have outlined an example case study of arranging a conference with the persona of the organiser and board member.

The team sat down and exchanged tasks, goals and ideas. We then started to construct a story map based on the conference organiser’s first set of responsbilities and workflow.

Conference Organiser Workflow

After the initial workflow you will notice the goal at the top linked to the persona.

The main activities are in the first row, divided into further tasks in each column which details each activity.

On a card we have further detail such as:

Detail on a card with checklist

After we established the conference organiser’s tasks we then expanded the story map to include the expanded responsibilities and workflow of the entire Team.

Workflow of the organiser and speakers

With this map now completed we can see the user workflow and what features we need defined.

Check out our completed map.

Next from this map we can develop and build a product roadmap.

Check in next week and have an introduction to designing our first MVP roadmap. Also check out from idea to MVP, a seperate article about building from the idea to the MVP.

Quick intro to Story Mapping

A story user map is a method for visually covering a story, to help discussions. The main purpose for making  a map is to build shared comprehension for the individuals of a team.

When building your story map, you should include all the relevent people, regardless of position, in the team. Due to their different foundations and interests, they all get valuable points of view. Everybody has an unmistakable and common comprehension of what they are about to build together.

Product owner, testers, technical lead, customer support, architect, UX/UI designer, sales and marketing, etc. All have their own techniques and requirements which will help you create your map.

How to build a story map

If you are brand new to user story mapping, we have a short and sweet exercise. Let’s take a simple real-life example of “getting ready for work”.

The StoryMap of Alex’s Morning
  1. Start with the goal.
    What is the story map about?
    What are you trying to accomplish?
    The main overall purpose.
  2. Second list your main stories, your main tasks or activities. From left to right, insert the main steps of the story map that need to happen.
  3. Move on and detail each main list – column by column, left to right.

In the case of product features, the layers can be then developed and you can plan out MVP‘s, or product iterations with each following layer.

When exploring product features, build story maps for multiple options that solve the underlying problem. Allow your entire team to contribute and come to and understanding of the final decision.

Story User Maps are ideal for allowing a team to design out a product feature and reduce the need to go back half way through development because XYZ requirement was missed out.

Check out our Getting Ready For Work Map

We cover three different user-case situations we can use Story Mapping.

Feature Definition

Product Roadmap

 

Story Mapping: A Reliable Agile Tool

When it comes to backlogs it can be overwhelming, difficult to grasp where we should go, or what we should prioritise. At times projects are entirely sidetracked by mismanagement of priorities.

To solve these situations a Story Map can be utilised to reduce the backlog, refocus the project and remind the entire team of the end goal.

When designing a Story Map you must look at the bigger picture. It is often sensible to set aside a period of time (hours or days) to effectively cover the vision.

You will need to set out the goals of the entire product, the ideals, the dreams, think big. To best utilise Story Mapping is the big picture, not just a sprint. Do not fall into the trap of a niche narrow sprint at this stage.

First write out the user stories by setting out functions.

Step 1 — Functions and user stories set out in a grid.

Horizontally, set out the title and set the user story under each function.
Vertically, set out the main stories or issues related to each other.

At this stage you can then prioritise importance from left to right, and from up to down. This creates a format of the top left card, being the most important.

Slicing the list.

Once the stories are organised into groups and themes. You can start with slicing the list into sprints of what is the Minimum Viable Spec, or as Jeff Patton puts it — “The minimium viable product in the smallest product releaes that successfully achieves its desired outcomes”.

Step 2 — You can see the sprints have seperated, clearly, what functions are required in each layer.

You can set sprints into what you need to achieve. The trick of utilising story mapping is by setting out the entire dream product, then breaking your product/project into sections of achievable, working, and required sprints.

Next Steps.

Do remember, the story map is not a static beast, it can be adjusted, amended with feedback, changed and adapted to suit the needs of each sprint.

With multiple team members working on it, as a team you can start to see the end goal, the ideal product and when working as a group you will be able to clearly define what each of you need. Too often I see teams all have an idea in their head turn out to be all differing versions.

  • Set status of a card
  • You can set time estimations
  • Set importance of cards
  • Use colours to set a custom identifier, such as challenge or complexity.
  • Use extra columns and set sections

The use of a story map will grow with each iteration, and with each demand.

Step 3 — Expanded map with colours, rags, and time estimations.

One thing is to ensure you are always planning the entire project, clearing backlog and not focusing on individual sprints.

If you want to see the tool we used for the images, check out FeatureMap.co