This is a project manager’s backlog for work to be completed on the application to find and purchase audio files, and mp3s. This is a snapshot of the tool under development with it’s MVP defined and work midway through it’s first sprint.
The tool was picked up by the new team as it had stalled, the new team used FeatureMap to define the MVP and continue forward.
This is a fun tool that one of our developers created to help them go shopping for Christmas. They literally created a list of people, ideal gifts and a process to keep on top of making their holidays stress-free.
It’s a fun map, and shows that you can bend FeatureMap to really cater to all sorts.
This is a map that a project manager and marketer created to help them identify a workflow and the requirements. Instead of a MVP and sprint, they operated with a very human “Must Have, Need and Nice to have” flow, allowing a bit of freedom while helping one another adhere to a set of rules.
It’s a step away from the usual design of what FeatureMap was made for, but as we said at the start. FeatureMap can be a canvas and only limited by your design.
Moviebuddy has been our go-to example for years. It’s from a product owner’s perspective, but also caters to the entire team.
MovieBuddy is an application to build a list of your movies for record keeping. The map expands, both through sprints horizontally, but also vertically it explores new features, sections and upgrades.
In the map you can see how it grows from being a simple record keeping piece of software, to a software for sharing, compiling automatically, finding new recommendations, complex listings and integrated wish lists.
Take a look and it may just inspire you.
So now its your turn…
You have some examples, some inspiration and hopefully some ideas.
If you’ve made a map, or a new design, reach out to us and share with us the map and template.
One beautiful benefit of FeatureMap is having maps shared with us and seeing the new and wonderful ways that imagination has been captured and put down into a map.
Creating a product map can feel intimidating, but with the right tools, it can be completed in no time. A systematic planning process and the right tool can get your project plan mapped out and finished in less than an hour.
A product map answers three basic questions:
What activities do you need to do?
Who will do these activities?
How long will these activities take?
It’s super easy, and it’s even better when you bring a team along with you to get started.
So how to start?
Step 1: Define your product
A story user map can be used as a method for visually outlining your roadmap for your product.
You will need to think of your product in stages, from high level to detailed level. Break your product down to varied groupings, then into steps, and then into further detail. Turn these steps into cards.
Product owner, testers, technical lead, customer support, architect, developers, UX/UI designer, sales and marketing, etc. All have their own techniques and requirements which will help you create your map.
With the questions above, what, who, why.
Step 2: Build that Map out.
If you are brand new to user story mapping, we have a short and sweet exercise. Let’s take a simple real-life example of “getting ready for work”.
Start with the goal. What is the story map about? What are you trying to accomplish? The main overall purpose.
Second, list your main stories, your main tasks or activities. From left to right, insert the main steps of the story map that need to happen.
Move on and detail each main list – column by column, left to right.
In the case of product features, the layers can be then developed and then bingo bango. Done.
In a simple step you have your Product Map of high level tasks.
Product Map complete.
And it’s only step 2… granted the product map would have been done as soon as you applied your main stories and really its more like step 3 if we need drag out tasks, but really… User Story Mapping as a tool for Product Maps offers a value you can only understand once it is underway.
Step 3: Now you have your Product Map – Let it breath!
Story User Maps are ideal for allowing a team to design out a product feature and reduce the need to go back halfway through development because XYZ requirement. Let the project develop, evolve and change into larger, bigger projects or features.
You can develop and maintain any feature creep by creating new cards and assigning them into new sections.
You can add new requirements and manage the product map by assigning times, values, budgets and aggregating those values to the higher level cards.
The product map can become the defacto aid and tool in all your roles as Producer or CTO!
When building your story map approach it from all roles, if alone think about each responsibility in an order and feel free to create duplicates to then merge later. It’s about going with the flow and giving creative freedom to fleshing out a detailed product map. You can always edit, merge, delete in a later step. Due to their different foundations and interests, all roles have valuable points of view. As well as when working collaboratively with a team, everybody has an unmistakable and common comprehension of what they are about to build together.
As an aside, for further reading, we covered a series intro to story mapping with a basic run down and a simple exercise taking you through the morning tasks and making a map that may help, also don’t forget to check out some good practises in going from Idea to MVP.
We have a two examples below.
One is the Audio Finder Project, a board finished, with MVP defined, sprints defined and using some aggregation on the cards. A good example to see a finished map.
One is the App for Lending Electronics, a board and map which is in the stage of “undergoing fine-tuning” and shows an example of half the map with tags and status applied, while the other half is still in flux. A good example to see a map undergoing evolution.
If you want to give making your product map a go, quickly, check out FeatureMap and start for free.
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.
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.
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 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.
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 Onlineand 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.
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:
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.
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.
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.
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.
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.
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.
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”.
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.
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.
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
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
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.
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.
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.
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.
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.
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?
Improves team involvement.
Allows to track project workflow.
Repeated work cycles.
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
No overproduction of tasks.
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
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
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:
On the Deck (This Spring)
Pending Testing (Approval)
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.
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.
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.
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.
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.
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.
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.
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…