User Story Mapping

Product-development teams can use story mapping to drive product discussion and align everyone's efforts at any stage of the process. Story maps can be used for new products after discovery work, or for existing products after usability testing. The user story map helps teams illustrates how the solutions can solve the problems research activities have uncovered.

Team norms: 👩‍🚀👩‍⚕‍🦸‍♂‍

Describe the high-level tasks that users aim to accomplish using the digital product, such as 'checking the account balance' or 'depositing a check'. (Usage process)

These will potentially be transform into "initiatives or epics" or just represent certain user activities.

Next, describe the activity or problem if needed (Details)

Steps appear under activities and are arranged sequentially. To complete the activity above, users will go through specific subtasks in the product. In the activity, Deposit a check, the steps are: Enter mobile deposit details, Sign check, Photograph check, Submit deposit, and Confirm deposit. (user tasks)

If you are a product manager, often steps can represent some of the user stories and can help you define some of the requirements.

Thinks about all the steps and use cases.

You can add additional details by adding a sticky note (use a different color) to describe the lowest-granularity interactions the team anticipates users will experience. These are often similar to product requirements like 'Enter email' ' Enter password'

Identifying the minimum viable product (or next release) and prioritizing it based on well-informed judgment by analyzing the User story map.

Team members can use story maps to visualize what their minimum-viable-product release could or should include, along with how and when to release end-to-end product increments with specific goals and outcomes.

Think about the requirements that are:

🔴 Critical: The must-have. Non-negotiable. We absolutely need this or the user will not be able to use/understand/buy our product/service/idea.

🟠Nice-to-have: The high-value features and ideas. The user will be able to reach their objective and the product/idea will still work but adding these additional features could improve their experience, users could pay more for the same product/service or increase their likelihood of converting into paying customers.

Discuss this with your team and make the final decision based on what you want to validate first. Also consider things like costs, time, etc.

Move to the next release those that are nice to have but can't be implemented for this release.

🟣Low: Small impact features and ideas. Ideas and features that aren't necessary but adding them to the product/service will have a small positive impact. Usually not adding these features or ideas will have zero negative effects. Ask yourself: what would happen if our team decides to move forward without adding this feature? If the answer is "nothing" or the negative effects are small this feature or idea belongs here or inside the "indifferent" quadrant.

🟡Indifferent: Customers don't care about it. (Avoid)