Story Mapping consists of ordering a project or product into tasks and organising each one into segments so you can better understand the whole picture and make better informed decisions for timelines, resources and roadmaps.
Such tools as Trello can be great for tasks or quick lists, but when you need more than a just columns. User Story Mapping utilises an agile methodolgy, incorporates sprints and gives you a broader view across the entire project.
When it comes to backlogs it can feel overwhelming, in some cases difficult to grasp how to start or what to prioritise. At times projects can be entirely sidetracked by mismanagement of priorities and a good Story Map of a product can highlight the Minimum Viable Project.
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. We have some further in depth guides and resources to read up which are linked again at the bottom of this article. But for now.. we’ll cover the basics as an intro to why Story Mapping is a reliable Agile Tool.
We have guides all across this blog, but to get you straight into it, lets do a quick theory crafting test.
You will need to set out the broad goals of the entire product… the ideals, the dreams, think big.
To best utilise Story Mapping is to tackle the entire big picture, not just a singular sprint. Do not fall into the trap of a niche narrow sprint at this stage. The power of User Story Mapping is being able to see the entire product and split it up into those sprints. To see what can the MVP, what can be the optimal, and even split the big picture into easy acessible projects.
First write out the user stories by setting out functions.
The fuctions could be “Logging in” or “Website Dev” or “Graphics Design”.
The limit is based on how you wish to organise. We suggest basic, and start simple as the beauty of working on a tool with many is the ability to adjust and change at will.
Good rules to follow: 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.
Once you have the information down in cads and across the board. Start to slice.
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 releases 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.
Wait… are we done already?
Do remember, the story map is not a static beast, it can be adjusted, amended with feedback, changed and adapted to suit the needs.
With multiple team members working on it, as a team, you can start to see the end goal, the ideal product. When working as a group you will be able to clearly define what each of you need.
Too often I have seen teams all have an idea in their head, start with a map and quickly realise their shared vision was mismatched!
The simple act of making the map together re-aligned with everyone on the same page, generated new innovations and removed any potential future unnecessary friction.
Next Steps.
Some more tips for the next steps:
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, descriptions, checklists, status, and time estimations.
One thing is to ensure you are always planning the entire project, clearing backlog and not focusing on individual sprints.
And all of a sudden you have a grasp of your project.
It really is that simple.
If you want to see the tool we used for the images, check out FeatureMap.co
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.
Does your current application need its legacy code rewritten to benefit from security, new features, modern integrations and to get with the new working world of remote WFH lifestyle?
Stop putting it off.
We’ll go over how to tackle the mammoth task and break it down to an approcable and task worth completing.
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 or plugging into an active project to help redefine the backlog, MVP and process. Afterall.. you need to start with your MVP or risk feature creep and stagnation.
FeatureMap can be used to help you plan out a current project or in this case, current piece of software. First approach the product/project/app and hash out the main features of the finished and current code.
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?
Take a moment, start you map and make a column and throw in ideas, thoughts, approaches, decisions. This is more for reference that you can draw from as you plan out the current software.
You can utilise basic User Story Mapping and decide where to place these cards, with which layers, columns and sections on your map.
Below and in these examples, we will refer ot our “Moviebuddy” app, a fictional app to help sorts your DVD collection.
The Moviebuddy Current Version
We then worked through identifying which sections were redundant and not required after the code update. We identified these and added them to a new column to the side. Essentially removing them from view. Some of these features were workarounds that the new framework would natively support so we can remove those, yet we still need to rewrite some of the related code. Be sure to add discriptions for your team to reference that may help them realise your decisions.
In this case, our team assembled and had an online meeting to identified which parts of the code would be updated and what we should be prioritised as a framework. We labelled this as version 1 and aimed to get the core functions updated. The MVP of re-writes.
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.
Re-writing your legacy code is so very typically neuenced and specific to your use case, but I hope with these examples above you can see how to:
Add your current app to a map.
Collaborate with your team to share the same understanding.
Highlight what is redudant.
Task and outline new expanded features.
Work through the MVP and assign with the team members.
Estimate time, costings and aggregate them for team leaders to quickly understand.
Rewrite your legacy code
Have a celebration
As you can see using User Story Mapping can be brand new projects, or old existing projects.
It’s 2021 already, stop putting that task off, realise how easy and approachable it is with a User Story Map. Break down the mountain to bite size tasks and update that out of date framework!
If you need direct advice, coaching, a guide or want to book some time to explore FeatureMap, do feel free to reach out to us, but first…
“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.
Shared by Jeff Patton, author of User Story Mapping – The Shared Understanding Problem.
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.
Seeing our goals visually on a map was a big help in shared understanding
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.
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.
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.
The world saw a huge shift in the 2020 working environment due to the Covid-19 Pandemic. While still here in many countries, and fears of third waves on the horizon, many are holding hope for the Vaccines that seem to be still shaping out the future landscape of the working world.
While some companies used to offer a work from home perk, it has fast become the go-to standard. Now in 2021 companies are transforming workplaces to places of collaboration, rather than a dedicated heads-down workplace.
Many companies are making the permanent move to dedicate a number or all of their team to a remote working solution. Dell want to move 50% of its workfoce to remote. Amazon have picked up over 3000 remote workers, and other companies such as Saleforce and SAP have been well reported as remote working companies.
With the economy, the after effects of the worldwilde pandemic, the stagnant wages and growing government state incentives. It is clear to see why it is predicted that by 2025, nearly 70% of the workforce will work remotely, at least part-time.
By 2025, 70% of the workforce will work remotely part-time.
Kate Lister, president of Global Workplace Analytics
A few years before the Pandemic; FeatureMap itself moved from its dedicated office space to remote employees across three countries. In making these changes, we identified more effective practices, saved on overheads and costs, and introduced a new culture and productivity.
As the pandemic forced other companies also turn to the remote online workspace, we thought it would be a good time to share some of our experiences and tips for getting the best out of your distributed team. We shared our initial thoughts and experiences in our last blog related to working from home. But how baout 2021?
We are here to help, so if your small–medium business is impacted by COVID-19, reach out to us at team@featuremap.co and see how we can find a solution for you during this time.
Working from Home
Things you need for your team to be successful while working from home remotely:
Team chat
Video conferencing capability with screen share options
Digital backlog management
Shared documents
Time management
Ways to stay connected with each other
Make your office space at home comfortable for remote working.
Team chat
There are many chat tools available online. We recommend Slack, Teams and Skype, but Slack in particular. It allows you to continue conversations throughout the course of work, either directly through private messages or in channels that act as meeting rooms. Everyone will be able to see discussions in these channels, so wise management using features like thread conversations will be key to an effective collaborative environment. You may already have a Microsoft solution and Teams have developed well in the last year.
Video conferencing
This includes daily discussions, team voice chats, and one-to-one meetings. We recommend video conferencing to encourage a continued level of professionalism, but being able to chat with somebody face-to-face can create more effective communication.
Good video conferencing software offers voice chat, video, and screen share. The ability to easily and quickly share your screen to your remote team during a meeting is time-saving gold dust. Zoom, TeamViewer, and Slack all offer this functionality.
However, be aware that both chat and voice calls can be disruptive if used unnecessarily: imagine getting called to meeting after meeting in the office!
We found a careful balance of start of the week meetings and end of the week meetings with ad hoc, required, progress meetings when required.
Common Problems
Remote work, does have its problems. Some people dislike working in the same place where they live, relax and can be hard to create a personal seperation. Other people require face to face, contact and interaction with people and the seperation can cause a disconnect. Some talk about the challenge of how to collaborate and state it is difficult to get on the same page with projects.
Luckily while we cannot help with the face to face contact. We can advise creating an area or state to help with the switch from work to personal.
Establishing discipline, dressing for work, and setting your desk or workspace in a particular manner. One trick I use is different coffee cups! Bizzare, I know, but it works!
Finally we can help with collaboration. Projects, teams, and remote working on completing a project, blacklog or product is the name of the game here at FeatureMap.
Digital backlog management
When you first start working remotely, it’s important to update the management of your tasks and responsibilities to your new environment. All those sticky notes on your monitor and scribbles left on your desk won’t work anymore. You have to go digital.
If you have a project manager, ask them to recreate your collaborative spaces in a digital space as soon as possible. Your remote team being able to access a single platform for project planning will not only help foster self-discipline but will also improve productivity. Ensure you use a tool that protects you, is easy to set up, and is clear, precise, and agnostic.
If you have any questions about FeatureMap.co, privacy, security of our online cloud or our on-premise options, drop an email over to team@featuremap.co
When we first created FeatureMap, we designed the fundamental principles based on Jeff Patton’s User Story Mapping model. Since then, however, we have evolved and developed to create a tool that can be used in multiple environments with a wide range of practices, including user story mapping, development, product management, team task management, agile workflows, kanban, and task lists.
When you recreate your collaborative space online, remember that utilising labels, custom fields, colour tags and assignments can really help you take control of your workflow.
Take your post-it notes and put them online for your team.
Moving to the digital space for project management
If you are moving from a physical workspace to the digital one, and are starting afresh, you will need to first identify and define the project’s backbone.
Designate a group of people to explore your project and identify the user experience and journey. Focus on the breadth of tasks first, then build in the depth.
If its easier we now support SAML integration to allow an easier onboarding process for On-Premise accounts
Using a shared workspace to collaborate live, whilst using video chat, can really help bring your session together as well as improve the quality of the end result.
Build a map and, if you need to, outline all the projects, cases, tasks and work within it. If you want to dig deeper into user story mapping while your team is distributed, check out our guide on how to get started.
If you are still uncertain and want a demo of FeatureMap.co, do reach out at sales@featuremap.co and we’ll be happy to schedule a live demo for a small team.
Covid-19 – Taking your physical to the digital with FeatureMap.co
Distributed team culture
Building a culture, keeping the team connection healthy, and improving communication with remote teammates is crucial. For this, team chat and communication is important. Adding a space where people can chat, share their daily lives, or simply talk before work or a meeting fosters healthy growth, keeps people engaged, and helps your teammates learn about each other. You can even build on this by creating virtual lunches together, having healthy competition about the “best lunch”, and more.
Try FeatureMap Today, and if you need more users, have feedback or suggestions we have new solutions for 2021 to help get you onboarded.
Do reach out and we can find a solution to help cover you while Covid-19 impacts your business.
Managing a project can be approached in a multitude of ways, and in 2021, with remote working and offices on the rise. User Story Mapping has rapidly stood out amongst the many agile methods. In one sentence, it can be easily explained as ordering a project (or product) into tasks and organising by priority and sophistication.
Let’s start with a brand new project, or we can take an existing project backlog. When it comes to backlogs it can be overwhelming, at times difficult to grasp, or what you should prioritise. At times projects are entirely sidetracked by mismanagement of priorities but user story mapping can resolve this.
Story Mapping 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 exploring your 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 minimum viable product in the smallest product releases 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 starts to form and when working as a group you will be able to clearly define what each task, and part of the project needs.
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
