High-Level Understanding – Utilising Aggregation in FeatureMap

User Story Mapping and FeatureMap

User story mapping can allow your team to see and understand the product from a user-centric design. You can see the bigger picture of the product, help the team identify gaps and dependencies, and give the first framework of a shared understanding between your entire team.

A finished FeatureMap Board should have your entire product outlined. The team will have sections separated, and you’ll be scheduling and planning the outline of prioritized stories into sprints and releases. 

In this article, we will share how to gain a better shared understanding of a map by utilising the feature of aggregation.

In short, it is the option of aggregating values. On each card you can assign a status, estimation and a budget. When you assign the aggregation option to a header card, the card will gather the values of all sub cards and calculate, dynamically, the overall status or number.

e you can see the FeatureMap Board of the Audio Finder Product, fully incorporated with aggregation of both status and time.
Here you can see the FeatureMap Board of the Audio Finder Product, fully incorporated with aggregation of both status and time.

A beautiful map, full of information, which can be daunting, but with ease you can see if the product development has any issues just by looking at the aggregated dynamic values on each of the layer headers.

Let’s break it down.

Status Aggregation

With Status, you are able to assign to a card, displaying a coloured icon on the main map. Great for that easy acquisition when viewing the larger map.

The statuses you can apply are: Todo, Ongoing, Done, Cancelled, Blocked.

With FeatureMap you can set statues to all cards to help with task management.
The Card – Register Online: Applying a status for the state of its task.

With aggregation, you can apply the option “automatic (aggregated)” on your header cards, and the header card will a value by priority to display allowing the team to see each header, and associated higher task status.

A quick glance at a busy map can be even quicker with good application of status icons, and aggregation allowing you to identify issues and solve them quickly. This is one huge advantage for those busy product owners or leads 😇

The priority for aggregation display is by importance: Blocked -> Ongoing -> Done.

When a card is set to “To-Do” and “Ongoing” are is aggregated as “Ongoing”.

  • When a column or layer has a “Blocked” card, this takes priority and is aggregated as “Blocked” as to draw attention to issues.
  • When all cards within a column/layer are done, the aggregated value draws “Done”.
  • The status “Cancelled” is ignored.

You can see Sign Up has been set to Status - automatic (aggregated)
Automatic (aggregated) has been applied to this Sign Up Card (Header).

The header card (groups) Sign Up has been set to an automatic (aggregated) value.

The sub headers (lists), Sign Up and Registration are also set to automatic (aggregated).

The cards in those columns have all be seen set with “Done” status.

The value will dynamically be displayed based on the values of the cards within the sub-cards.

In this case, FeatureMap draws the values from Register Online and Email Confirmation.

Both are “Done”, so the value aggregated is “Done.”

Budget and Estimation Aggregation

The task status is not the only aggregation option. You can also track your assigned values of budget and estimation.

When you assign numbers to a card, and then aggregation to the header. It will draw vertically to each header group and list or, if applied to a layer header, it will draw horizontally to each layer. This allows you to see the overall bigger picture, but also a specific collection of times, costs or the main status of the project.

In this FeatureMap we are utilising Aggregation.

On the User Management Section, we are not aggregating status instead we are estimating the time it will take for our developers to code the described section.

You can see the Dashboard Options Card is estimated to take 15 hours, and the Dynamic Windows Card is estimated to take 20 hours.

The header above – Dashboard draws those numbers and calculates both, giving us 35 hours. At a quick glance, the team now know the Dashboard feature should be done after 35 hours.

This aggregates higher to the USER MANAGEMENT header as well, showing us the value of 76 as it draws all estimations in it’s sub lists of Dashboard, Interact with Review and Social Media Elementals.

Customising the Aggregation Options.

On both Estimation and Budget, you can rename the labels of these fields and assign units.

If you decide to do this after the fact, worry not, you can assign the field settings to a single card, or all cards on the map when editing the options.

The list of options available when customising your fields.

To edit, open up a card and click the grey cog wheel next to the Estimation or Budget field.

Here you can rename the fields, and assign units.

Units available are:

  • none (default)
  • points (pts)
  • EUR (€)
  • USD ($)
  • weeks (w)
  • days (d)
  • hours (h)
I settled on Estimation and used the units as “hours”.

Apply to all cards please, and let my map be beautifully informative.

Vertical or Horizontal

Aggregation can be applied horizontally or vertically.

When you apply it to the Group and List Headers (Vertically) the aggregation will be drawn from the entire column, spanning every sprint or value.

As such, it is much more common to see the aggregation applied horizontally to see the Sprint status.

Aggregate up or across. Dynamically see your sprints and tasks.

Aggregation Helps

A user story map need not be static. Teams can update it with findings from research spikes, revised estimations, and user feedback from sprints and releases. The story map can also be used as a visual roadmap to communicate both the planned work and the work that remains.

So if you find yourself as a product owner or project manager wondering the status of your developers, and you want to avoid it interrupting them distracting them or holding unnecessary meetings, the aggregation tool is invaluable for your management.

It allows your developers to keep you updated while allowing an optimal level of communication. Maybe they’ll get more done? 😀

Give aggregation a go, you’ll be surprised how much control it gives to your map. You can access aggregation options with a Premium Subscription, or with the free sign-up trial.

Happy Mapping!

How to Recruit More Users for User Discovery Interviews on Autopilot – Continuous Discovery Made Simple

As a product manager or product designer, you’re constantly thinking about how you could improve your product further. 

Most of the time, this means building new features, or improving existing UX. 

With FeatureMap you can build out your maps, get a visual broad understanding, but what about supporting your next steps?

How do you know if the features you are planning to build are what is going to really drive user value, while pushing your company closer towards its revenue goals? 

You can use prioritization frameworks, of course but first and foremost you should…talk to your customers. 

And Teresa Torres, a renowned Product Management expert, wants you to talk to them more often! 

Let’s see how you can recruit more users for your interviews without spending more time and effort on it – and get better results from your product delivery efforts? 

What is Continuous Product Discovery? 

Continuous Discovery Image of a slide. Weekly touch points with customers

Continuous Product Discovery is a mindset of developing a weekly cadence of having conversations with your customers. 

The term has been coined by Teresa Torres, an authority in the field of product management, who recently published an eponymous book on that topic. 

Image of book Continuous Discover Habits by Teresa Torres

The expectation that you will start talking to your customers every day or even every week, if you’re not talking to them at all now (or once in a blue moon) is a bit like going on a crash diet – an extreme change that is not likely to last.

Continuous discovery implies a continuous improvement mindset – if you talk to your users quarterly, take a small step and talk to them monthly. If you talk to them monthly – try talking to them bi-weekly. 

Now – you may be asking yourself – why bother to increase the frequency of talking to your customers at all? 

Why is Continuous Discovery important?

We make product design decisions every day. But we talk to our customers every…6 months? What happens in the meantime? 

You’re more likely than not to work on features that nobody wants, or that the users are likely to find confusing.

Learning from user behavior only after you have launched is very expensive. If you find out that the feature you’ve just launched was a big mistake and you basically need to go back to the drawing board and redo it – you’ve already wasted the precious time and resources. 

This could have been prevented through exposing your users to the planned features at the stage of paper sketches – making the whole process easier and cheaper. 

Escaping the “Build Trap”

Book cover of Escaping the Build Trap by Melissa Perri

Continuous Discovery also helps you to understand your customers and users a lot better, thus avoid falling into the ‘build trap’ – a situation where the product team is stuck in the cycle of building and launching features, without giving much thought to the outcomes. 

This term, in turn, was coined by Melissa Perri, an author of another great book for PMs on that topic.

The Curse of Knowledge

Another reason why you should employ Continuous Discovery is our “curse of knowledge” as PMs. 

We are experts, but our customers are not. 

They are not familiar with our products. They don’t know the ins and outs of our interface. What seems “so obvious” to us may be total rocket science for them. 

In consequence – we make product decisions that are not good for our customers, from an expert point of view. 

Validation mindset vs. Continuous Discovery Mindset – it’s cheaper 

PMs tend to have a “validation mindset” – they build things, and then A/B test them to check if the users are getting them. This mindset, however, is very expensive. 

Continuous discovery mindset, in turn, helps us test our hypotheses a lot earlier in the process – before we have built anything. 

When we get feedback at an early stage, on “paper sketches” and half-baked ideas – it’s faster, easier and cheaper to iterate. 

This is what we call the co-creation mindset – where the customer is actively involved in the feature creation process. 

You shouldn’t ask customers what to build 

Henry Ford Quote - If I had asked people what they wanted, they would have said faster horses

A common objection to continuous discovery is that “customers don’t know what they want.” 

You may recall these famous Steve Jobs quotes, or even Henry Ford’s famous If I had asked people what they wanted, they would have said faster horses.”

This sentence is actually quintessential to explaining the common misconception about Continuous Discovery. You should never ask your customers what they want. Your customers are not aware of what’s possible to do with technology.

That’s why you shouldn’t ask them what to build. But you should totally liaise with them over what you decided to build early, to get feedback and see if they see it as easy to use, valuable or important as you (once again – the curse of knowledge is a thing!) 

Who should do Continuous Discovery? 

Hopefully, if you’ve reached this point in the article, you’re at least to some extent convinced that you need Continuous Discovery. 

But who’s supposed to do it? Do you have to hire a product researcher? 

You will feel relieved to hear that, according to Teressa Torres, the answer to that question is “no”. 

The team responsible for Continuous Discovery should be the same as the team that is building the product, on a weekly basis. 

You don’t want a hand-off between a discovery team and a delivery team. Your delivery team should be talking to the customers too. 

The product “trio” is the minimum team that is doing discovery. They should focus on having small, but frequent touchpoints with the customer. 

We need to do research in a way that discovers customer value that drives business value. 

How do you discover features like that? 

Opportunity solution tree helps you find opportunities that increase financial metrics by increasing customer value at the same time: 

Video still of The Opportunity solution Tree

Ok, so now you’re probably wondering…how on earth do I get my customers to talk to us, especially in the busy B2B world?

Problems with Continuous Discovery 

Apart from finding the right people to conduct discovery, and finding time (and motivation!) to do it consistently – you also need to find the users who will want to jump on a call with you. 

Filling your calendar with customer interviews may have been a challenge, but it is now becoming increasingly easy with digital adoption tools that can be used to recruit users for discovery calls on autopilot. 

How to recruit users for Continuous Discovery? 

How to fill your calendar with user interviews without even thinking about it? You need to ask your users when they are already engaging with your product: 

  • You can do it directly on your website, by showing a popup with a link to your calendar
  • You can get your customer-facing teams to recruit customers for user interviews – e.g. your Customer Success or Customer Support teams. 
  • Or – if your buyer persona is the same as user persona (e.g. in B2C, or SMB-B2B) – the best way to do it is inside your app. 

Make it in-app 

Your users are most likely to respond to your bid for connection – and accept an invitation to a user interview – after they have successfully accomplished something using your product. 

You can do it by building reactive in-app experiences that appear only when a custom event has been triggered by the user: 

Backlink manager example

BacklinkManager asks the users to jump on a quick, 15-minute interview after the user has launched their first link building campaign. 

Offer incentives 

As you can see in the example above – offering a small incentive in the form of e.g. an Amazon voucher, or a discount on your annual subscription or upgrade – can make it more likely that the users will book a call with you. 

Make it relevant 

If you have a more complex SaaS product, it’s likely that you cater to different audiences and personas. Using segmentation will enable you to reach the right audience. 

You can then invite a specific segment of users to interviews focusing on a particular problem you’re trying to solve for this specific audience segment. 

This is why you should use user segmentation to trigger interview requests. 

Audience Triggering Example

With tools like Userpilot, you can easily segment your users both by demographic and behavioural characteristics – e.g. by user attributes such as plan, or by the role in their organization, or by custom events such as e.g. performance of certain actions in app (and the number of such actions) or the use of certain features. 

Make it timely 

Time is also of essence. You don’t want to invite a user to an interview after they have just failed to complete a certain task, after they’ve contacted your support about a problem or a but that hasn’t been successfully resolved yet, or you have an indication that they are unhappy with your product or service based on their low NPS score. 

In such a situation, the user will be very unlikely to respond to your invitation to an interview, and it may even frustrate them further (as the in-app invites inevitably interrupt their workflow). 

Hence: you should make sure you excluded these users from the audience you’re targeting with your in-app experiences, e.g. by excluding users who have not performed certain custom events, have contacted the support a certain number of times in a specific time period, or have a low NPS score: 

You can use NPS as a triggering criterion in Userpilot. 

Ways to invite users to a Continuous Discovery interview in-app

There are different UI patterns you can use to invite users to a continuous discovery interview.  

The one we showed above – called modal, is the most popular one, but you can also use a more subtle slideout: 

Tooltip highlighting example to draw attention and collect feedback

Or a tooltip highlighting a specific element on the UI, if you want to collect feedback on a specific feature: 

Or a banner sitting on top of your screen. 

You can build these invites completely code free with several onboarding tools, like Userpilot or Appcues. 

Best in-app Continuous Discovery tools 

The banners, modals and tooltips inviting user to a discovery interview can be built without coding in Digital Adoption tools – however, some of these tools are more useful than others for Continuous Discovery. 

For instance – some digital adoption tools such as Walkme or Whatfix are used for employee onboarding on third party apps such as Hubspot or Salesforce rather than building in-app experiences for the end users. This means they are more complex than necessary and have a significantly higher price tag than onboarding tools. 

When it comes to value for money, the best product adoption tool for creating user discovery interviews is Userpilot, followed by a more expensive Appcues. Userpilot will be your best choice if you need to build in-app experiences code free in Responsive Web Apps, but if you need Salesforce integration, Appcues may be a better option.

Source: userpilot.com

For mobile apps – Pendo is currently the best option on the market. 

Conclusion 

Continuous Discovery can help you save a lot of time and resources in the process of building new product features. And it’s possible to recruit your users for discovery interviews on autopilot, using product adoption tools you may already have implemented for user onboarding. 

With a little bit of foresight and segmentation, you can fill your calendar with user interviews automatically, and foster these good Continuous Discovery habits. 

About the author

Emilia is Head of Marketing at Userpilot and a product marketing enthusiast. She has experience of working with several SaaS businesses as a marketer and a co-founder. Her passion for content marketing, SEO and SaaS products led her to build Userpilot’s whole content ops, hiring system, and documentation from ground up.

Product Owner Skills: What Do We Need?

It is essential that Product Owners in 2021 have a wide variety of skills. Soft skills (skills that are hard to measure) and hard skills (easily defined and specific skills).

Soft skills (such as communication, leadership, and creativity) and hard skills (like sales, data handling, and proficiency with development tools) both help create the best Product Owner. Gaining experience and knowledge in both skills is challenging and rewarding, but the soft skills are naturally harder to define and therefore harder to measure improvement.

Product Owners Boost your soft skills and enhance your collaboration, leadership and creativity with FeatureMap.

The role of a Product Owner is to lead, defines the work flow of the project, organize and prioritize the backlog of the team and streamline the project while maintaining the conceptual and technical integrity of the product. Heaps of hard skills, glued together with that all important management of individuals via soft skills.

A product owner can however help themselves with the use of Tools which complement and enhance those soft skills. User Story Mapping, and the use of creating a map and running a mapping session with the entire team, can really help boost and compliment your backlog management or project planning.

In LinkedIn’s ‘The Most In-Demand Hard and Soft Skills of 2020’, the top three soft skills are creativity, persuasion and collaboration. Three top skills that are required in Product Owners and Project Management.

With User Story Mapping and FeatureMap, you can give your creativity a boost as you create a map with ease, layout your product in easy organized cards, columns and utilizing the basic Agile design. Linking in immediately you can super up your collaboration as you bring your team members onto the board, and your entire broader team can fill in their own user story journeys, discussing and building a map together.

Seeing the bigger, larger, broader view of a project gives your decision-making and leadership a boost.

With the broader view, and bigger picture, you can give your persuasion and leadership that supported weight and sell your decisions to your team and stakeholders.

As a Digital Product Owner, you are at the helm of the product.

You will be the one responsible for ensuring the product is on track, and the product vision has been achieved.

You will be responsible for influencing cross-functional teams.

Why not give yourself a secret weapon?

Conversation is Crucial with User Story Mapping

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.

 

How to create a user story map in 7 steps

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:

  1. Sign up for an account
  2. Search for the track by genre/year/artists/album
  3. View/listen to the song track
  4. Enter payment information
  5. Buy track
  6. Download track
  7. 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

You can view the example map here, where we have enabled public sharing to allow anyone outside the team to view: https://www.featuremap.co/mp/aRV8c0/audio-finder-project

Maintaining a User Story Map will allow you to continue with an organised approach, power up your management and team communication.

If you want to see more guides, check out some other blog posts, or if you want to see another example – check out Movie Buddy Map.

Get started now for free right here.

Story Mapping Can Help Your Team Understand – Remote Offices in 2021

Shared Understanding - A buzzword to describe group knowledge

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.

Scrumban, Kanban, Scrum, Agile, You can do it all.

Over the last 10 years (probably more) the boom of Agile methodology has continued to rise with the need to harness a high performing, high impacting workforce. Project nanagers, teams and companies have adapted its methodologies and the search and battle of Scrum Vs Kanban has become a well known and familiar comparison.

Scrum, and Kanban are two methodologies that come under the wide umbrella of Agile Methodology, both have benefits and drawbacks, but combining the pair has led to some success but still retains its overall pitfalls. Over the last year the move to remote working has become a necessity for many work forces.

Scrumban involves applying Kanban principles to a team’s Scrum framework. Scrumban removes some of the more rigid aspects of Scrum and leaves teams to develop their own adaptation which can give a huge varied experience.

So what do the two methodology bring?

Scrum

  • Fixed requirement.
  • Improves team involvement.
  • Allows to track project workflow.
  • Repeated work cycles.
  • Deadline.

Scrum is an Agile framework that is designed to focus on maximizing the team’s ability to deliver quickly, to respond to emerging requirements. Common practice is to explore and set a fixed requirement to tie in with the fixed deadline. The Scrum process requires the use of fixed-length development cycles called sprints, which usually last between 1-4 weeks.

Scrum came about in the late 1980s, as a commercial product, self described as “a new approach to commercial product development to increase speed and flexibility”.

Scrum teams are designed to be small, cross-functional, and self-organizing. Teams split work into small, shippable product increments, and sort the work by priority and relative effort. The product owner selects all work to be done in a sprint at one time, then the team spends each sprint completing the work.

How a typical Scrum board looks in FeatureMap.co

Scrum Board at FeatureMap
Using the basic features of FeatureMap as a Scrum Sprint Board.

Kanban

  • No overproduction of tasks.
  • Flexibility.
  • Limit Work in Progress (eliminate waste and people focus).

Kanban was introduced by Toyota in the 1940s, and was largely used in the manufacturing world as a visual workflow management methodology. Work items are represented by cards on a board, with rows that represent process steps. Boards are used by teams to manage the collective work of the team. They minimize chaos and promote focus by explicitly limiting how many items are in process at any given time, using a tool called WIP (work-in-process) limits.

Teams practicing Kanban measure lead time (average time from when work is requested to when it is finished) and optimize their processes to improve lead time, with the goal of achieving a continuous, predictable flow of value to their customers.

The downside of Kanban is how it is based around manufacturing, and as such has strict and inflexible method of change as it assumes a stable product flow.

How a board of Kanban looks in FeatureMap.co

Using the basic features of FeatureMap as a Kanban Production Board.

So why would you be interested in Scrumban?

Scrum + Kanban

Scrumban combines the structure of Scrum with the flow-based methods of Kanban. So what of Scrum is incorporated into the Scrumban method:

  • Iteration planning at regular intervals.
  • Decide work load in each sprint based on the complexity of the work and the length of the sprint
  • Extended Board
  • Prioritization on demand
  • Use “Next/Ready” column to help organise.
  • A fixed deadline helps identify and focus work flow.

Kanban adds visualization, process, and flow. These are the elements of Kanban that are used by Scrumban teams:

  • Pull items into Doing adapting to the teams capacity
  • Individual roles are flexible.
  • WIP limits: Limits on how many items are in the backlog and progress.
  • Short lead times – just-in-time in stead of batches.
  • Focus more on deadline adaptability to the WIP and MVP.
  • Clearer step transitions

In a Scrumban Board you can see the merger of both Scrum and Kanban headers:

Backlog (Queue)On the Deck (This Spring)Next (Ready)SpecifySpecifiedDoing (Development/Active)Pending Testing (Approval)Testing (QA)DeploymentDone
An example merge of the kanban and scrum headers to make the ideal scrumban.

Scrumban boards are taking the best bits of Kanban and Scrumban, but is this enough?

The FeatureMap solution

A Scrumban board can hit some of your goals, and if you are looking and wanting more, FeatureMap offers a hybrid solution of Kanban, Scrum, and User Story Mapping. The tool can hit all the marks and is entirely flexible. In fact in some scenarios so flexible it can be daunting to the unprepared how best to utilise this powerful tool.

Scrumban is useful when it is difficult to predict the amount of work. It is useful with combining flexibility, adaptability and monitoring tools of Scrum, and a Kanban board.

FeatureMap adds that extra tool, how to map the entire product with your team, online and with tools and access to Kanban, Scrum, Scrumban or your own hybrid method.

You can combine the best of both worlds, with a scrum board and carefully not mixing the cards, but at the same time using layers to retain a sense of roadmap, listing prioirites. An enhanced scrumban board with more dimensions.

Want a card to have tasks? – Done
Want a card to be assigned to an individual to track? – Done
Want to have priorities, colours and custom status tracking on all cards? – Done
Want to assign an entire row, column or grouping to an individual to team? – Done
Want to change the entire map on the fly for a better solution? – Done
Want an aggregation feature to show pricing, timing or estimations on cards below and groupings above? – Done
Integration? On-Premise? REST API? – Done

FeatureMap is not limited to a scrum, or column only approach. It is not limited to a kanban outline. It was originally designed by engineers for their own products. It later took off and became its own self sustaining application based on Jeff Patton’s User Story Mapping methodology. Taking the persona of the target individual, audience, market, requirement and building the demand of a project/map/product around that.

But lets keep to the Scrumban design and restrict ourselves to the standard flow.

FeatureMap utilising the hybrid approach of Scrumban, Kanban and Scrum

On this board we have split the flow of the transition from left to right into 4 main columns.

Within each column:

First the backlog, set tasks that are known or in discussion, set here and at a high level, placed in a loose month set. The queue of tasks to be arranged.

Secondly the Development column is split into 4 different states – blocked, progress, pending and confirmed. These represent the flow of coding, or manufacturing. You can see in these cards two icons of myself, a little face which represents the card being assigned to me, so I receive notifications of comments, checklists, dates and status updates.

Third, the QA section is simply split to “To review” and “Verified”, so tasks can flow from developed, to quality assurance. and ready to be reviewed. In the screenshot above, you can see one card highlighted in yellow. With FeatureMap any card can be highlighted a variety of colours, easy to draw attention or to be set for a predetermined meanings.

Fourth and finally, the last section lists “Delivered” an area for final review from the project lead, to accept and sign off completion.

As well as the main “June” horizontal layer, we can see multiple layers of dates, June, July, and “Later” which can also be adjusted on the fly by various teams to move cards up and down, dynamically with their expected

FeatureMap can be utilised as a tool for more than User Story Mapping. It can be a tool for bringing your project and tool under control, and with an advantage.

FeatureMap offers multiple solutions, but for this case. It’s the perfect Scrumban solution.

The Customer Facing Story Mapping Solution

In 2020, the pandemic forced businesses to adapt and move to to remote solutions, projects had to revisit back logs with adjustments from the physical to the digital.

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.

To see an example demo map check here: https://www.featuremap.co/mp/FviDEf/moviebuddy

You can get started with FeatureMap, and if you need more help or ideas, check out our 5 reasons to use User Story Mapping or a specific idea such as Feature Definition.

From Idea to MVP

User Story Mapping - From Idea to MVP

User Story Mapping is the perfect tool for taking an idea of a group, and refining it with shared understanding into a perfect MVP.

If you are just starting or have a project that is stagnant or facing a barrier, read on how to easily figure out if you have a product already, or how to best start the planning process in 2021.

When we look at User Story Mapping, you may think of the backlog of user stories, or how it can be a great methodolgy to reduce and refine your current project or product flow. But User Story Mapping doesn’t just need to be a tool applied to a backlog heavy project. It can be used to refine an idea to a product.

Refine the Idea

To start, you’ll be going on a User Story Mapping journey. Take your product and start writing out all the steps out, be as broad as you want.

Take the product and ask yourself and your team these questions:

  1. What is the overall idea?
  2. Who are the customers?
  3. Who are the end users?
  4. Why would they want it?
  5. Why are we building it?

Find out what the project and product is for, validate your reasoning, search for problems, take the steps to refine your idea.

Build to Learn

With the initial idea fleshed out, build your product with the aim to learn. A less than MVP (Minimum Viable Product), a product that covers the simple basis for your users.

With this stage you do not want to market, push or give out the product as “The product” but instead share with a small group of users. Ideally users you spoke to initally that may have sparked the idea of the product or are in your alpha/beta group and open to seeing the progression.

As part of this step you need to harvest the feedback, and constantly refine your idea. Build wants but be care ful to actually listen to what the user wants.

At this stage metrics will help as it is common people will fall into a loose three categories:

  1. The Polite Enabler. — The user who says everything is great, but doesnt use the product.
  2. The Complainer. — The user who sends in lists of feedback and demands, but actually uses the product.
  3. The Mute. — The user who uses the product and says nothing.

The polite user is probably the worst for building to learn, with the complainer being your favourite user. However be careful the complainer is not just demanding features that detract or do nothing.

The Mute you’ll need to reach out, engage and ask for feedback with offered incentives. The mute can be valuable if you can change them from mute to talking.

If you are reading this to get started, you can get started straight away for free. You get given a premium trial for 2 weeks when you sign up, but even if you revert to a starter account you’ll still have access to edit, move and make your map.

You can get signed up, but if you are planning, read on for now.

Applying it all to a Story Mapped Backlog

You now have your project released, some feedback and ideas of how to take it from big idea to big success.

For a practical start, we recommend organising a horizontal strip of User Actitives. You will have this from the first step, and the questions. This will form the backbone and be the foundation of your map.

You can lay it out how you like, but if you want guidance you can lay it out in vertical strips, and arrange it into three tiers:

  • Current Relase
  • Next Release(s)
  • Future Ideas

Each card will have indepth details about the feature.

Example Layout in FeatureMap.co

Then when organised, take the highest priority stories or layers and move into the current sprint.

This is one great way to refine your Idea down to a core set of principles. You can find out your MVP.

When I created my app, I went beyond the MVP and made the pre-MVP core functions. This allowed me to generate an ugly, functional core system to then expand on. I never released the pre-MVP but it helped me define the principles of our app.

Common Pitfalls

I might write a piece entirely about the pitfalls I see new projects and products fall to when designing their story map and MVP but for now, the key two points echoed everywhere:

  1. Perfection — When designing a product do not focus and lose yourself to the “Just one more feature” which adds time and bloat to inital ideas.
  2. Make a skateboard first — When making a car, first design a skateboard that allows the user to at least get somewhere. Do not fall into the trap of building car parts with no method to go.

To illustrate this Henrik Kniberg wrote an article talking about how he prefers “Earliest Testable/Usable/Lovable” over MVP.

Henrik Kniberg

I was once hired to salvage a project. When I started digging into the functions and principles I found that they had been in a state of “not yet ready” and “coming soon” for over a year. I learnt that each time they had developed a section the designers, artists, and owners all had differening ideas of what they all wanted.

I first sat them down with a task of shared understanding, figuring out exactly what everyones vision was, and how it translated to actionable steps.

Then secondly I highlighted they already had a MVP, and had an MVP since the year prior. We seperated the whole system into stages (the horizontal sprints) and were able to wrap up and release the project.

If translated that to Henriks image above, I realised they were at stage 3, while they were aiming to develop to stage 5. Stage 5 before they had even earnt a penny.

Do not do it.

Summary – Validate your MVP

So to summarise.

When designing your product, each sprint sent to product should be reviewed, measured and with feedback and data. To learn.

With that learn knowledge, collect data, read feedback, refine your idea.

If it ever seems out of kilter with the rest of your team, you shouldn’t worry as you are all working on a Story Map, you will all see the steps and sprints. That shared understanding of the project elimates the issues.

With that refined idea, revamp your MVP and build.

  • Build — MVP
  • Measure — Get feedback and data
  • Refine — Improve with better ideas
  • Repeat — Back to Build.

With User Story Mapping this is easy, especially when using a tool like FeatureMap.co as the ease and flow of a team all working, moving and adjusting cards on the fly makes it invaluable.

Get started today, and get your project working. You may already have an MVP!

Shared Understanding – Benefits of Story Mapping

Shared Understanding - A buzzword to describe group knowledge

“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 Understanding in 2021
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.

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.

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

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.

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.

How to get Started?

Getting started is easy, assembled your team, open up a map and start talking!