User story mapping has become a go-to technique in Scrum for effectively capturing and visualizing user requirements. While Product Managers and Agile teams commonly leverage this approach, user story mapping extends its benefits to various stakeholders involved in the Scrum process. This article will act as a comprehensive guide for Agile Product Development. Indeed, it will explore how the different users in Scrum can harness its power to drive successful product development.
Product Managers
As the orchestrators of product vision and strategy, product managers play a vital role in user story mapping. Not only do they utilize this technique to gain a holistic view of user needs, but also prioritize features. User story mapping helps product managers identify gaps, dependencies, and opportunities, enabling them to make informed decisions that align with the overall product vision.
A holistic view of the roadmap provides insightful information on the overall progress of the project
Scrum Masters
Scrum Masters act as facilitators and coaches for the Scrum team. They play a crucial role in ensuring effective collaboration and communication. Hence, user story mapping serves as a valuable tool to guide and facilitate user story discussions and sprint planning. It helps them create a shared understanding among team members and fosters a collaborative environment.
Development Teams
As for development teams, they are at the heart of the Scrum process, responsible for transforming user stories into working product increments. As a matter of fact, user story mapping helps development teams gain clarity on user requirements, dependencies, and priorities. It enables them to plan their work effectively, break down stories into actionable tasks, and align their efforts toward delivering value to end-users.
Designers
Next, user story mapping allows Designers to understand the user journey and design experiences that meet user needs. By visualizing user stories, designers can identify touchpoints, pain points, and opportunities to enhance the user experience. They can collaborate with product managers and development teams to create intuitive and user-centric designs.
Stakeholders
Finally, stakeholders such as executives, customers, and business analysts, benefit from user story mapping by gaining visibility into the product development process. The tool provides a clear picture of the product’s direction, timeline, and expected features. All stakeholders can actively participate in discussions, provide feedback, and ensure alignment with business objectives.
Easily leave comments or discuss with all stakeholders on the selected card
All in all, user story mapping is a versatile technique that caters to various users involved in Scrum. From product managers shaping the product vision to development teams delivering working increments, each stakeholder benefits from the shared understanding and collaborative environment fostered by user story mapping. By leveraging this technique, Scrum teams can streamline their processes, enhance communication, and deliver products that truly meet user needs.
Start embracing the power of user story mapping and unlock the full potential of Scrum!
You would like to implement user story mapping in your team but don’t know where to start? Check out our games to Teach & Learn user story mapping! Use our premade templates as a basis or read through our step-by-step guide to create your own from scratch!
Are you tired of feeling overwhelmed by your backlog and deadlines? Do you want to improve communication and alignment among your team? Look no further! A User Story Mapping Workshop is the perfect solution. Not only will it help identify problem areas, but it’s also easy to teach and can be introduced with a simple game.
In just 30 minutes, your team will learn how to use this powerful technique to make the most of their time and effort. Don’t let fear of the unknown hold you back – give User Story Mapping a try and watch your team thrive!
Teaching User Story Mapping to your team can seem a little daunting to newbies when you first pull up a full FeatureMap. Luckily, User Story Mapping is easy to teach, and I have a great simple exercise to walk your team through as an introduction.
The technique is innately simple and can be taught with one simple game (because if we say game instead of exercise, it sounds better, right?).
I have some exciting and engaging 30-minute games that you can use in your teaching workshop or as a starting point for a User Story Session. These games will not only help your team develop a better understanding of User Story Mapping, but they’ll also have fun and build team cohesion along the way. So why wait? Add some fun and learning to your next workshop and watch your team thrive!
How to conduct a User Story Mapping session and teach!
Running a user story mapping session is fairly straight-forward and you can get sorted quickly.
Here is an easy set of instructions broken into 8 steps:
Begin by explaining the concept of User Story Mapping and its importance in the product development process.
Provide an overview of the steps involved in conducting a User Story Mapping session, including how to identify user needs and create a shared understanding of the product vision among team members.
Divide the participants into small teams and give each team a scenario, such as developing a new mobile app or a website for a small business.
Ask each team to brainstorm and identify the different user needs and goals that the product should address.
Have the teams create a rough draft of their User Story Map, using sticky notes or a whiteboard to organize the user stories into columns representing the different phases of the product development process (e.g. planning, development, testing, etc.).
Ask each team to present their User Story Map to the group, explaining their reasoning behind the organization and placement of the user stories on the map.
Facilitate a group discussion to identify common themes and areas for improvement in the different teams’ User Story Maps.
Conclude the exercise by summarizing the key takeaways and reinforcing the importance of conducting User Story Mapping sessions as part of the product development process.
By participating in this exercise, team members will gain hands-on experience in conducting a User Story Mapping session and will learn how to use this tool to create a shared understanding of the product vision among their team.
Get to Work!
One of the easiest and well known games is the “Get to work” or “Wake up in the morning” tasks.
You write out on your map what you do each morning. This can be broken down to the most mundane steps.
I once had a team member write out everything they did which included an impressive rising time of 4am and 3 hours of morning preperation. I have since added to the challenge that they only have 20 minutes to get up and to get out the door to get to work.
What you can do is expand the task to reduce the time available, and to extend the time available to experience with what they add and cut aka minimal viable product! 😉
Another game that can be used to introduce the concept of User Story Mapping without the need for cards is called “User Story Jigsaw.” This game involves dividing the participants into small teams and giving each team a set of user stories that are related to a specific product or project. The teams must then work together to organize the user stories into a logical sequence that represents the product development process.
To play the game, first, create a set of user stories that are related to a specific product or project. These user stories should be based on the real-life challenges and needs of the team or organization.
Next, divide the participants into small teams and give each team a set of user stories. The teams should then work together to organize the user stories into a User Story Map, using sticky notes or a whiteboard to create columns representing the different phases of the product development process.
The teams should then place the user stories onto the map, trying to create a logical sequence that represents the flow of the product development process. The team with the most effective User Story Map wins the game.
After playing the game, the teams can discuss their User Story Maps and compare them to see how they differ and what they can learn from each other. This discussion can help the participants gain a better understanding of the concept of User Story Mapping and how it can be applied in their own work.
Tic Tac Toe Game
another game that can be used to introduce the concept of User Story Mapping is called “User Story Tic-Tac-Toe.” This game involves creating a grid with different user stories written in each square, and then having the participants take turns placing their “X” or “O” on the grid to organize the user stories into a logical sequence that represents the product development process. The objective is to create a User Story Map that covers as many squares on the grid as possible, with the winner being the team that creates the most effective User Story Map.
To play the game, first, create a grid with different user stories written in each square. These user stories should be based on a specific product or project that the team is working on.
Next, divide the participants into two teams and give each team a set of “X” and “O” markers. To begin the game, one team should place their “X” on the grid, choosing a user story from one of the squares. The other team should then place their “O” on the grid, choosing a user story that is related to the first user story.
The teams should continue taking turns placing their markers on the grid, trying to create a User Story Map that covers as many squares as possible. The team with the most effective User Story Map wins the game.
After playing the game, the teams can discuss their User Story Maps and compare them to see how they differ and what they can learn from each other. This discussion can help the participants gain a better understanding of the concept of User Story Mapping and how it can be applied in their own work.
Final Tips for your Workshop Games
Using games and exercises to teach any product or methodology will be met with variation. Be aware of your audience, what will work and tailor your tutorials to fit them.
Some important tips for running these games.
Clearly explain the objective and rules of the game at the beginning to ensure that all participants understand what is expected of them.
Encourage collaboration and teamwork among the participants, allowing everyone to contribute their ideas and perspectives to the User Story Map. Try to discourage any“leader” roles who make all the decisions, let the entire team contribute.
Provide guidance and support to the teams as needed, helping them to understand the concept of User Story Mapping and how to apply it to their own work.
Focus on keeping time for each exercise to be utilised well, we often recommend under 60 minutes.
Use a variety of tools and materials, such as sticky notes, whiteboards, and digital tools, to allow the teams to create and organize their User Story Maps in the way that works best for them.
Debrief after the game to discuss the teams’ experiences and what they learned from the exercise. This can help reinforce the key takeaways and provide additional insights and guidance for applying User Story Mapping in the future.
Consider providing additional resources and support for teams that want to continue learning and practicing User Story Mapping after the game or exercise is over. This could include access to online tutorials, workshops, and other learning materials.
User Story Mapping is innately simple, with a huge range of depth that can be demonstrated in deep and powerful maps. If you need more assistance or ideas, check out how some of our templates to inspire.
In 2020 we saw the rise of Remote workers. In 2021 we saw businesses, that were ahead, embrace working from home and remote workers. With the shift, came the realisation that conversation is king when it comes to project management. Communication, communication, communication.
User Story Mapping is the tool for a team to build out, or embrace a project. It enables you and your wider team to come together and design your product in full.
In essence, a simple story idea is; write something on a card, talk about it, converse and agree on what to build. -> Complete the build and move to the next.
It sounds simple, but in a working environment, it is normally vastly more complex. Stories end up going through multiple processes, cycles and conversations. Stories end being created with 3 main needs. A card for the business, a card for the user and a card for the developers. Luckily User Story Mapping is something that can absolutely lend itself to this process.
The Right Size for the Right Story
A tried and tested method to help develop your Map is utilising the “right size” method. Break down each part of the project/prodocut until it fits the “right size”.
For example, when writing a User Story Map with a team, you loosely fall into three categories:
The User.
The Business.
The Developer.
The user’s “right size” is a story or card that fulfills a need.
The businesses “right size” is a story which bundles features, outlines updates, themes or new products. First it is set-up as a Minimum Viable Product and following releases are the right size which helps a business achieve a business outcome.
The developer’s right size is the most efficient for designing, building and testing.
Really you can define these to your preferences, but if you are unsure, use the above outlines.
Big Stories Break Down to Smaller Stories
Big stories (or epics) can be broken down to smaller stories, and then again even smaller. Each sprint/epic/story/card can be defined for each group but no matter the size, they are still a story.
To break down larger stories, use conversation.
Conversation is one of the best tools for breaking down big stories.
Discuss and Discover
When you discuss with your team, break down each story until it fits the “right size”.
Each size will vary from business to business, and project to project, so don’t define too much. Use conversations to allow you to naturally identify the “right size”.
When you discuss, dig deep into:
Who the user will use your solution.
How the user meet their needs without your solution.
How it would change with your solution.
How your solution would look and function.
How long will your solution take to build.
Even after your discussed discovery session, don’t stop talking, don’t stop collaborating.
With each step, each conversation will have different teams and different conversations, in particular, the main three, so do note each evaluation will vary.
Yet with each conversation, each meeting, each get-together, this can lead to slow down, so be aware of how you plan your meetings.
With FeatureMap you are able to construct your maps and have constant, flowing conversation on each card, story or epic. Have your entire team chime in, discuss and do so remotely. Allow this process to be part of the working stage eliminating unnecessary meetings for all and saving time and money.
With each card, story and sprint you design and build, every single card will have consequences, re-explore these, discuss them, confirm them.
Conversation is King with User Story Mapping so get started, and save time and hours, Plug in your exisiting work, or start anew.
User story mapping is an agile methodology with a focus on product design/development. It doesn’t stop there, but in this article we’ll focus on product design. Designing with user story mapping is one of the secret weapons to create a user-centered product. The product design process always begins with first understanding the problem and the user’s goals. The power of this, is the ability to spec out multiple users, mulitple goals and clearly display our entire process whilst following a natural, narrative flow of the users journey.
User Story Mapping can be narrowed down to organising user goals, activities, and user stories. This can help your product flow or backlog and create an visual backlog, that everyone understands.
Why is it important to create a User Story Map for your project?
Your customers need a simple way to confirm product goals.
Your teammates benefit from such a straightforward platform.
Teammates can get access to the entire scope and see and add valuable ideas.
Developers can see the entire specification for the product.
To sum up, user story maps are the visual aid to building shared understanding between project members.
Creating a user story map can take time, but you can follow a pretty clear and logical process, with a good efficient start you’ll be ahead in no-time. This could be a solo task, but to the absolute advantage of a user story map is to use it as a tool to have discussions with your wider team team.
What you’ll need: Grab your team, your VOIP of choice, boot up a brand new Map (Create from scratch) and sit back with a meeting blocked out for the team.
Do note, this is not a presentation but an involved group activity, so be mindful of voip etiquette.
Step 1: Frame the journey
Before you start mapping, you want to frame the exercise around a common goal. This could be your product vision or the goal of a specific feature you’re mapping out.
One of the simplest ways to do this is just to ask: What does our product do?
If this feels too big or gets too unwieldy, think about some constraints you can add to your user story mapping session:
What? – What problem are you trying to solve? What product do you want to build or what feature do you want to add?
Who? – Is there a specific user or user group you’re building for? Who are your potential customers?
Why? – Why build this for the user? What is the benefit to your team and company for building this feature or product? How will giving users this add value to the bottom line?
Talk it through and make sure everyone understands the vision and overarching goal of the user story mapping session.
Be aware, you may find such varied views from each other this may outline some sticking points from the get go!
Step 2: Build your story backbone
The backone of your map covers the entire journey described in high-level tasks or steps from start to finish. Don’t get too detailed, that comes at a later task. Go wide, not tall. Discover your goals and map your journey.
As an example, let’s say we’re building a product that helps someone buy a record track. At the highest level, the steps they take are:
Sign up for an account
Search for the track by genre/year/artists/album
View/listen to the song track
Enter payment information
Buy track
Download track
Interact with social/stars/review of track.
Each feature or step can get more indepth later and expand out with sub headings, cards and individual descriptions.
Your product is probably a lot more complex. Here are few ways to help identify your backbone:
The expert details the journey: Ask one of the subject matter experts to walk through the problem step-by-step. How do they tackle this? What steps do they take and what tasks do they perform?
Everyone creates cards and inputs on the map: As you create cards on FeatureMap, get each familiar team member writing their own cards and detailing their journeys. Everyone can input the steps that need to be taken and add them to the map. Don’t worry about duplicates now, as this may highlight misunderstandings or merge tasks to a better project flow.
Brainstorm with your team to collect the most possible solutions and put all user stories under the related steps.
Once complete, think about the ideal user flow. The use case. Does the map fit and cover all steps for the journey?
What if you’re working with an existing backlog? If you have a backlog full of well-written user stories you can simply add them into your map. In some cases, this might even be the majority of your steps and you could utilise an API, or import features from JIRA or Trello.
Step 3: Identify and group your cards
As you look through the steps your user takes, you’ll start to notice some common groups, or activities that could be placed within groupings. In user story mapping, we call these activities.
Your activities (also known as user stories at this stage) are listed above the user steps (or epics) to make up your backbone.
As an example, lets return to our previous product of buying a record track. Here we can build out a step:
Search for a track by genre/year/artists/album
We can break this into individual cards of:
Search for a track
Search for an artist
Search for an album
Search within a genre
Search for a genre
Search tracks within a year, or a specific year.
You can see how these could all be individual tasks with a group of “Search for a track”. Here we can, with relative ease, start to identify user steps, user stories that all correlate to a user goal.
User Goal/Activity – Find a Track. User Step/Epic – Search User Story/Card – Search for an artist, then search for a track.
Step 4: Break large tasks into subtasks
It’s time to go a step deeper. The cards in your backbone are most likely too big to be tackled in a realistic single sprint. This step covers breaking down those cards and activities into smaller groupings and user stories.
Step 4 involves your team editing cards, splitting them into two, rewriting and reorganising them. Cards here could be reorganised and moved around the map. Placing cards into activities/sections/groupings will making it clearer for all involved promoting that shared understanding.
One key point of advice – Do Not Get Bogged Down!
FeatureMaps and User Story Maps are living, breathing things, cards get developed, edited, added to and when first mapping out the entire user story aim to cover it all at a higher level scope first.
Step 5: Fill in missing tasks.
This step has you expanding, checking for missing task, filling in the blanks.
Ask your teams if they are covered and user story is represented no the map.
One simple and effective test is to have someone walk through the scenario from a different user perspective. This is what is called utilising Personas. Act out the steps as your user and allow the team to highlight when missing steps/cards/goals are not on the map and have them add them.
Each department will see this differently, for example the graphics and UX design team may differ on presentation while the coders are thinking about stacks and the sales team are thinking about pain points and upselling.
If a team member states “Ah ha, this is missing or may cause problems…” then this stage is doing well.
Step 6: Prioritise your activities and cards.
Your Map and backbone is how your users move through your product. Each section at this high level are equally important, building blocks to the entire product/project.
Here you can easily see the whole picture and work with your team to find the best minimal viable product. This stage is ideal to figure out what has the highest priority, while allowing other sections to be put aside.. for now.
Now that you have the user map prioritised vertically, you can create horizontal “layers” that represent your MVP to Full release.
A good practice is to ensure that each layer should be creating value across each user and activity.
Step 7: Maintain your Map.
The last step covers using your living, breathing, evolving map.
Checking up your progress, see quickly the wider picture of your team.
Ensuring cards and tasks stay on track, assign deadlines to individual tasks and adjust work flow carefully.
In FeatureMap you can assign dates to tasks, cards or groups to keep track of progress.
You can assign cards to individual team members, and add progress status to each card, such as “todo, progress, done, etc”
You can expand and add timings or costings, or other custom metrics and utilise the aggregation tool which allows you to see the combined time within each sprint, grouping, or the larger map.
Audio Finder – A Fictitious Project about finding audio tracks and downloading them. Viewed as a User Story Mapping Board on FeatureMap.co
When working with a large organisation it is not uncommon for everyone to picture the product from different angles, resulting in an understanding of the project or product in different ways. Story Mapping can help your team understand, bring those meetings to the digital and allow your remote working team to gain that shared understanding.
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 or two different features due to a bad understanding of the spec. These teams could be in the same office, or spread across the world. The challenge and solution is the same.
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 conflict of understanding. Two different CRM systems and a product completely overlooked by the other teams, with overlapping cards.
Without using a FeatureMap Board, this error may have gone unnoticed for an unspecified amount of time.
Cut down your time and mismanagement, introduce a macro level understanding and make your job easier managing your team. If you are a team member, you can understand the entire project/product and figure exactly how best to utilise all talents and input.
Mapping your story helps you find holes in your thinking.
When we set out and built an entire map, 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.
When starting with FeatureMap, it doesn’t matter if you are mid project, or at the start of a new journey.
Mapping out the entire product, even at a high level macro level will help your entire team progress forward.
You can start with FeatureMap today for free, with an instant 2 week trial to access all the extra features such as aggregation, import, export, enhanced status cards and alike.
With that came the need to communicate and work with clients and customers remotely. Luckily User Story Mapping is the perfect method to visually cover the entire scope of the project/product, to help discussions, and gain a shared understanding direclty with your client.
When building your story map, you should include all the relevant people, regardless of position.
Each member invited will offer 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.
Bring in your Client
This advanced tactic is to involve the customer/client with a map designed as a Customer facing Story Map.
Customers have probably seen roadmaps, or gannt charts in the past but to truly involve a customer with your plan of development or project outline is to utilise a Story Map. A Story Map can show your progress with a beautiful planned out snapshot. Allow your client to choose where to zone in and understand.
In the example below, we took our Moviebuddy map, a fictional product which helps you arrange and organise your DvD collection and had our development team plan out the requirements for each user story. We needed to share with our client what exactly we planned and if our vision was shared.
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.
In another instance, a video game developer shared their planned game development, their beta and was able to get thousands of players to see the progress, suggest plans and help develop an ideal release. The access to so many eyes of potential customers, potential users was invaluable for feedback and further development.
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 with FeatureMap?
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.
If you are new to User Story Mapping or have already done user story mapping, it is highly likely that you’ll be doing Remote User Story Mapping online in 2020.
Since the pandemic we have seen over 31% of the US Workforce migrate from offices in March 2020 to working from home in April 2020.
Already we see businesses changing the way they work, creating permanent changes to include remote working, hot desking, partial office attendance and in some cases, removal of the office entirely. It is clear that if we seek out a positive from all this, the education of a better work-life is certainly one.
One downside of the removal of a physical office space is the ability to carry out planning, and if we look at User Story Mapping – the ease to create a board. This is where FeatureMap comes in as an online digital space.
Lets go over the 5 things for a successful remote User Story Mapping session.
It may take a few days, may take a week, or may take a quick catch up over the day. Whatever the use case of your group is, and the required time, be sure to keep in mind the differences between working in the office and working from home.
Figure out an agenda, plan the day over introductions, activities, presentations, and when to carefully place the breaks.
For some, working from home can be distracting, while for others it can provide a freedom and comfort to allow them to work efficiently. Cater to everyone.
Is everyone on the same timezone?
Will everyone be available for the full time?
Social time?
Can you create a course?
Get your Tech in order.
If you’ve been in any meetings with people new to remote working it can derail the meeting to tech support and cause all sorts of issues.
Ensure everyone is ready with their hardware, software and prepared to participate and collaborate.
This will be basic things such as:
Your main communications, be it Teams, Zoom, Skype or Slack – ensure everyone is signed in, ready and working.
VOIP, Headphones, Microphones, audio tests – Ensure everyone is good ahead of time. There is nothing worse than having one person spend 45 minutes troubleshooting a microphone.
Webcams working – These are great to make the remote working feel like you are all in it together.
The PC and Internet! – Basic basic basic tests. Make sure it all works.
FeatureMap Accounts – signed up, invited an in the correct map ready (either in a trial if new, or setup with the group leader if business). We’ve made this bit easy ?
You can send this out pre-meeting and ensure everyone can do a mock load, test and make sure they are ready to go 9am the day of the course.
Set out clear rules
So this is more of a per group basis. I’ve sat in meetings where everyone is completely new to remote working, and I’ve sat in groups where it is a tried and tested done deal. The huge range of experiences were staggeringly immense – talking over one another, crunching of food, tech issues, volume, lag – oh my.
Set out some rules to ensure your remote user mapping session is productive:
One person talks at a time
Ensure everyone has had time to participate
Check chat frequently
Eat only in your break
Good audio and camera (put your webcam on!)
Mute your microphone between conversations and don’t hot mic!
In an ideal world, your remote colleague might be in a self contained home office, free from distractions and sound – but in a real world… sometimes the kids, dog, neighbours or even home office equipment may not behave. So give slack but also be aware of your team and work to these requirements.
Meeting Execution
Now we have our tech sorted, our plan, our rules and accounts. It is worth considering that working online for long periods of time can be extremely tiring and regular breaks are recommended.
One simple rule for remote working is that when scheduling meetings plan them to finish 5 minutes before the end of the hour, or before the half hour, to build in time for much needed breaks.
Here are some basic tips for running effective online sessions:
Manage Talking Time – Communicating online can take longer, typing, thought process (the removal of visual feedback) but also allow clearer and direct communication. However it can take time so try timeboxes. Use a timer, visible to all, to ensure conversations do not drift.
Visualise Information – Share sources of information when referring to it in the meeting, use your dedicated channel to get a clear visualisation. This is an important goal and why the User Story Map and its visual collaboration is important to be real time.
Avoid repetition – Maintain engagement, and keeping attention is important as so you do not need to repeat coverage. There are many tips to do this, but random selection or asking the last person who spoke to choose who speaks next is a good way to keep everyone alert and listening to the course.
Records and Notes – If the call needs to be recorded, or notes do so in an online document. Webcams at flipcharts, photos of whiteboards can deliver a very poor and low impact experience. While you’ll have the story board covered with FeatureMap, it is important to ensure accompanying tech to deliver a strong course.
One thing 2020 has shown us – Remote Working is here to stay, so get ahead of the curve and ensure your team is productive and effective.
User Story Mapping can seem daunting when you first pull up a full FeatureMap. If those on your team are not familiar with the technique it can really slow down your sessions. Yet the technique is innately simple and can be taught very quickly.
Here I outline some of the quick and easy 30 minute games that you can add to your teaching workshop, or that you can go over yourself to help share or gain a n understanding on how to approach user story mapping.
Get to Work!
One of the easiest and well known games is the “Get to work” or “Wake up in the morning” tasks.
You write out on your map what you do each morning. This can be broken down to the most mundane steps.
I once had a team member write out everything they did which included an impressive rising time of 4am and 3 hours of morning preperation. I have since added to the challenge that they only have 20 minutes to get up and to get out the door to get to work.
What you can do is expand the task to reduce the time available, and to extend the time available to experience with what they add and cut aka minimal viable product! 😉
Another exercise is to add a time limit, deadline and propose they prepare for a vaction.
Setting my team of 1 month to there vaction they had to go through steps of checking passport, renewing, booking flights, checking luggage, buying missing items, packing, items, etc.
After the team had planned what they needed to do, you can again add time restraints such only 1 week to plan, and even only 1 day.
Doing this can education again the MVP and how to adjust and move the map around to suggest the best plan.
Describe an existing product
A good exercise to describe a common well known product, or even if a competitors product. This exercise can be used to take the focus from games and activies to a more development and industry focused task and will later help with your projects.
The last time our team covered this we had just seen a recent update to Spotify so we outlined and described the product, desktop, browser and mobile.
We explored the application and spent some time designing the task out, splitting it into sections and then created the foundation or backbone of the application.
When you have created the backbone product you can then start adding extra features in sprints, or even removing tasks and features to create an application lite, in this case it was “Spotfiy lite” or a media player.
We ended up designing Winamp!
We then ended up designing a fictional application about movies called “Movie Buddy” which we now use as a demonstration FeatureMap still today.
The Moviebuddy Current Version
User Story Mapping Exercises
Using games and exercises to teach any product or methodology will be met with variation. Be aware of your audience, what will work and tailor your tutorials to fit them.
Some important tips for running these games.
Keep the time taken per exercise to under 30 minutes
Split each task of a game into 5 minute periods.
User FeatureMap or good old fashioned sticky notes and markers.
Use walls, floors or tables.
You can always do a final lesson of converting sticky notes to digital
Discourage a “leader” who may make all choices, allow all particpants to take part.
Try to aim for 30 tasks.
If you are teaching, do the tasks beforehand so you are able to help with prior experience on the subject matter.
User Story Mapping is innately simple with a huge range of depth that can be demonstrated in deep and powerful maps. If you need more assistance or ideas, check out how to 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.
