5 Reasons to use User Story Mapping for Project management.

5 Reasons to use User Story Mapping for Project management.

It can be a nightmare when planning out a project or joining a team to plan the project and you are met with Word documents. It is even worse when the customer and your team are expected to settle on the design outline of a word document with no future changes.

Requirements always change as customers and teams discover more about their project as it progresses. Expectations change, development requirements are adjusted, improved upon and developed and tracking all these changes in a Word document leads to madness.

User Story Mapping is a clear-cut methodology that let teams plan software releases that create visual maps of customer requirements. User stories are typically written on sticky notes or developed on a virtual map with absolute collaboration. (FeatureMap).

Here are five reasons why you should utilise User Story Mapping for your next project.

1. Prioritize the most important requirements.

Story maps let teams identify the really important reuqirements, and then allows the team to real-time amend and edit the map with development and feedback. While doable with sticky notes, the interactive collaboration of FeatureMap allows on the fly editing and at a glance live progress.  With a story map, teams can prioritize the most important features first and deliver code based on the prioritized features.

Built in sprints allowing a basic MVP program to be released before moving into sprint 2 and building the next product.

Features can be identify and built in sprints in multiple MVP states with ease, rather than developing one function in its entirety. It allows you to build your function, then at a later stage refines the features across with each iteration. You can easily identify what is most important and what is a core feature. Splits large requirements into small slices

2. Enforces task separation to encourage smaller sprints.

Cards and Post-it notes have literal maximum space. A good habit is born and can be utilised for your User Story Map creation. You have to be brief in the requirement description. If the requirement description is too complex to be stated on a single card, simply break it up into two cards. Create to functions, two tasks which can be split (if required) into multiple sprints.

This again allows the project to be refined and delivered on time with clarity and simplicity.

No more twenty page documents!

3. Communication with the stakeholder.

User Story maps aid with communication with the customer/stakeholder. Each customer requirement is then aligned with a task or card, the customer can understand at a glance what functionality will be delivered with each sprint and release.

With FeatureMap you can create a map for your development team, and share it publically to those with the URL link, the customer will see, real-time of your development map. Alternatively, you can create a map from a map (like cloning) and then share that map as a “snapshot” of the progress. And of course, you can export the map in a multitude of ways.

If the customer wants a feature delivered earlier, the customer can see which stage the feature or card is in and if involved in the process can adjust the map.

See this map as an example: https://www.featuremap.co/mp/5lJ74H/markus-goals

4. Communication with the team to help define and manage trade-offs and objectives.

Potentially the most important benefit. Using a User Story Mapping map will boost communication and discussion. Visual thinking is common in approximately 60%–65% of the general population, leaning on statistically your team will benefit too.

Having this visual aid and 2D map will reveal questions of all participants in the early phases of the project, which will lead to more quality and faster product backlog creation.

This will allow you as a Project Manager to keep on top of trade-offs and manage features and the project objective.

Communication helps define projects with ease

5. Visualisation of the entire Roadmap

A story map can focus the stakeholder and team to see a snippet. It can reduce that 200-page word document of completed tasks, or charts of completed tasks to a visual map of completed sprints and planned development.

The focus is smaller and the stakeholder can visually understand the requirements being delivered in the first release, second release and subsequent releases. The stakeholder can pay more attention to the relevant requirements (and requirements always change).

The customer can see the first release and following releases at a glance

The customer here can see the current release and the solving of an issue, but can also tell at a simple glance that the “even better mega solution” is in the next release.

User Story Mapping can be utilised in a multitude of ways. Project Managers can step in and compliment their planning with a digital version of User Story Mapping and work with the team, developers, customers, and even users for feedback.

If you want to learn more about building a project we recommend “easily testable” to “useable” then to “loveable” rather than building a broken bike in all stages. Read more in our Idea to MVP.

If you wish to learn more about FeatureMap check out our Intro to Story Mapping – RoadMap.

How to re-write your Legacy Application using Story Mapping

People often mistake User Story Mapping as a tool to start projects, but it is entirely suitable for building up an old project or design.

When looking at your application it is easy to first create  User Story Map based on the products functions.

Establish the tasks, the goals and flesh out the map. Sometimes you may taken things for granted and forget certain tools of the application are actually tasks so it’s a good idea to bring in people from other teams to help identify all the functions of your project.

Build the map, identifiying all the functions.

We once took an old tool and needed to update the codebase, as well as introduce new features and improvements.

A few options may be available to you, depending on the code. Are you able to update the tool in sections? Are you able to approach the update in sprints/versions? Do you need to rebuild the entire program from scratch?

We first built the map of our tool, you can see below our “Moviebuddy” example.

The Moviebuddy Current Version

We then worked through identifying which sections were redundant. We identified these and added them to a new column to the side. Essentially removing them from view.

We then talked out and identified which parts of the code would be updated and what we could do first. We labelled this as version 1 and aimed to get the core functions updated.

Identifying what we should upgrade first in Version 1

We were able to identify one function which we were able to upgrade. We also added new cards which reminded us to update our code standards and highlighted them green to ensure they were completed.

We then moved along to the next version which allowed us to introduce our new payment gateway to the application. A function that had alluded us due to the old codebase.

Adding a new Codebase column and moving to version 1.5

This allowed us to deploy more frequently and provide value sooner as we updated sections of the site. We still had a lot of ‘old legacy code’ but as we added new features we moved the legacy code functions inline with our updates.

As you can see using User Story Mapping can be brand new projects, or old existing projects.

Moviebuddy is all fictional for the purpose of training.

 

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.