Story Mapping Can Help Your Team Understand

When working with a large organisation it is not uncommon for everyone to picture the product in different ways.

When you have multiple smaller teams come together to create a product, each team can have different requirements. This can clog up development and in some instances waste time, building the same features in multiple different ways.

A few years ago I was assisting in the development of a now-popular mobile app. The team of designers all had different ideas on the end goal and it wasn’t until we mapped the entire user story that this was realised.

Confused Team Mapping Out Individual Requirements

The managers wanted to see a CRM in the backend that would allow them to see the flow of products and users and to manage the support workers and content creators.

The content creators wanted to have a CRM in the backend that allowed them to edit, create and update articles and products.

The sales team wanted to have a map system that would allow users to find a product based on location.

Shared Understanding with a Shared Vision

When we put all three together we could see an overlap of two different CRM systems and a product completely overlooked by the other teams.

Mapping your story helps you find holes in your thinking.

When we set out and built an entire wall, it was clear that each team had a different idea. Once they were able to list each card across the map, teams merged ideas, worked on the initial idea and framed the entire product.

Once the ideas had been merged, expanded and realised, the team was able to expand their understanding to a shared understanding.

Shared MVP Achieved With Understanding

The team were then able to split up their design into a minimum viable product that successfully achieved the desired outcome.

Sadly, it was realised that months had been wasted on planning features of a project with no compatiblity with the rest of the team.

Fortunately, when creating their product on FeatureMap (even linking with remote team members across the world) they were able to hash out a new plan and deliever well within time.

Mapping your story helps with shared understanding.

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