“Shared Understanding” is a well known buzz word, or common expression, in the User Story Mapping and project management scene. It really easily breaks down to a common group concenus of a projects. Getting to the point of a common shared concensus can be met with pitfalls and misunderstandings without even realising the issue is there!
Paul, Alex and Simon can all believe they agree and understanding one anothers design idea…. but do they?
User Story Mapping is not strictly a method of building software as it can be applied and utilised in a multiple of ways, but for this.. it is perfect.
The main drive is to result in a shared understanding, to expose the absolute “given” in philsosophy.
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.
Check out FeatureMap and start your trial now.
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.
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.
Seeing our goals visually on a map was a big help in shared understanding
Project Manager in this case.
Before using FeatureMap to plan out their goals, the team used multiple shared documents, lists and tasks. It was possible to achieve what they sought, but it was certainly wrought with overlapping issues.
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.
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.
Which teams should be involved?
Really, the answer is as many as you can.
- UX/UI Team
- Agile Coaches
- Software Engineers
- Product Owners
- Product Managers
- Customers
- Marketing Teams
- Executives
User Story Mapping is better when a group advises, rather than an individual.
How to get Started?
Getting started is easy, assembled your team, open up a map and start talking!