Story Mapping: how to map features of the product around the user needs
After reading a user story, the team knows why they are building, what they’re building, and what value it creates. User stories provide an excellent
Positive user experience comes first. Building user-centric software starts with creating a meticulous user stories. We work on detailed user stories map making sure software users needs are met.
We at Moqod apply an efficient, customer-centric agile methodology. Thanks to user stories, we make sure that the value of the software fits the end-user. We work through every scenario, and map them around his/her needs. By means of detailed user stories, we are able to analyse users’ behaviour employing data. Thus, the software development process remains iterative and lean.
Stay focused on your business vision while being involved into software development.
Sharp user stories, allow us to provide understandable project roadmap and deliver predictable results.
User stories help to build software based on users' needs and has higher chances for commercial success.
Clear user journey matched with business goals help the team to deliver software fast and effective.
Investing time into creating user stories returns with a boost of your development team effectiveness and alignment.
While the insides of each user story vary according to the product, most of them follow the same pattern with a series of steps. A user story includes the user, the narrative, and the final goal. A classic formula canonized by Mike Cohn for a user story is:
The flow of a user story begins with a specific aim in mind and how to efficiently get the user to the finishing line.
Understand the final goal that correlates with your ideal customer. How will this feature deliver value to the user?
Work on user personas. Who is this solution made for? If there are multiple personas, consider creating a story for each of them.
Prioritize the user stories based on their goal, value, cost, and user personas. Define which ones are essential to the functioning of your product and start with them.
Describe the experience step by step. How the user persona gets from what he needs to what your product offers? Look for variations and exceptions.
Measure feedback from real users to define success. The easier the user gets from point A to point B, the higher the chances he will get back to your solution.
Organize user stories: with sticky notes on a whiteboard or choose one of software programs created specifically for user stories.
A large higher-level user story is called an ‘epic’. Multiple epics make an initiative. They give a bigger picture, and it is recommended to decompose an epic into smaller stories, if possible. Think about it in Cory Miller’s words: How Do You Eat an Elephant? One Bite At a Time!
When it comes to measuring the effectiveness of stories don’t settle with ‘it is kind of working’. Make sure it is working perfectly for the ideal customer and thus develop only what is needed.
In software development, user stories are specific descriptions of how customers use a product. It is a definition that comes from Agile methodology. They are written from the user’s point of view, in the language that the user will understand. More particularly, they focus on one certain functionality, detailing in several sentences how the user will get to the feature’s goal.
Stories mapping helps you save the development hours by outlining the user journey first. Story mapping is done with the team at the beginning of the development. One of its main advantages is that helps bring the whole team onto the same page regarding the phases and the flow of the process.
User stories can be written at any time during development. Usually, story mapping takes place at the beginning of the development, to prioritize parts of the development workflow. However, when you work with Agile methodology in sprints, changes and additions are expected to appear in the process.
The team member who is the most suitable to write a particular user story should write it. This means that anyone can write user stories. Usually, you would want people from different departments working on the same story. It offers better insight from different perspectives and ensures a high-quality result on all levels.product.
A user persona is a fictional character with real-world human features. It is based on the ideal customer and has a combination of the qualities of such a customer.
Very often, you will end up with larger user stories, aka ‘epics’. User stories compose an epic, they are the micro-parts of the future product. To break down the process, make sure one separate user story focuses on one feature. Think of breaking a chemical element into units, where the smallest one is the atom, and there nothing deeper than the atom.
User stories focus on the final result, while user cases focus more on the process description and understanding of what the team is working on. The user story starts with the goal in mind. A user case is a case that already exists, with a detailed analysis of the system and how the users act within the system.
For example, you can prioritize user stories by using the MoSCoW method:
Must-haves, Should-haves, Could-haves, and Won’t-haves. You rank the stories from those that are a ‘must’ to make a successful project to the user stories with the lowest necessity and highest costs.
Another way to organize user stories would be to decide on which are
– Urgent and important
– Urgent and less important
– Non-urgent and important
– Non-urgent and non-important
There are other prioritization methods, based on cost, time, and value, on the complexity or on the Highest Paid Person’s Opinion (HiPPO). Together with your team, you can decide which one fits you best, based on your user, goals and values.
The first thing to remember is that one user story will have several test cases. There are several approaches to achieving one goal. A test case should be well written, extremely detailed and done in simple words.
One case shouldn’t test everything possible. Focus on one case per action for clarity.
If a user story becomes obsolete during the process, it’s best to not delete it or mark it as done. Create a folder for unwanted user stories in case you need to reflect back on the history of story mapping.
You should NOT write a user story if a) a feature doesn’t have a specific goal = it doesn’t solve a user’s problem. You should NOT write a user story even if the goal is valid but it doesn’t correspond with the issues of your dream customer. You should NOT write a user story if you don’t know who your dream customer is.
For a smooth, effective user story, the end-user and the goal have to be in sync.
After reading a user story, the team knows why they are building, what they’re building, and what value it creates. User stories provide an excellent
