1. What is Story Mapping?
At Epic level, the product backlog can be easily understood by the development team because it is generalized & clear about product priority & roadmap. However, when Epic is broken down to User stories & tasks, the product backlog will become very large and very detailed. The project team may have difficulty understanding the role of each User Story in the product roadmap, in the user’s workflow & priority, the relationship between the User Story.
Story Mapping is a method of visualizing the product backlog, helping the development team & Product Owner to build a backlog, prioritize & reinforce the overall goal of the product.
2. Benefits of Story Mapping
- Visualize the product backlog from a user perspective : Story Mapping helps the development team understand what functions are needed for a user to complete a workflow, the order in which the functions are implemented, and the importance of each function in the application. workflow.
- Help prioritize the product backlog : Story Mapping draws a big picture of the entire product roadmap, how stories & epic are linked together in the product context, & partial release plans. Based on Story Mapping, the development team understands the priority of each story, the relationship between the stories and the risks involved in the development process.
- Help the Product Owner break large epic into user story
- Building consensus & common goals : Story Mapping session is a teamwork activity, and members of the product development team can get involved, raise ideas & ask questions. After Story Mapping sessions, all members have a grasp of the product roadmap, the story behind each user story, the Product Owner’s expectations, as well as the scope & complexity of the product.
3. Subjects participating in building Story Mapping
Story Mapping should have members with different backgrounds & perspectives. A Story Mapping session can have from 4 to 8 people, including:
- Domain experts, testers, UX designers: people who have knowledge about the users & functions of products
- Development team: people who directly work with the product backlog & answer the question “How long does it take to develop each user story”
- Other subjects: those who are interested in the product & answer questions related to the operation, revenue & impact of the product on the organization
4. When to build Story Mapping
Story Mapping is a long-term activity that can take place many times during development. Story Mapping is the planning step that takes place before the Sprint Planning session (Story Mapping’s output is the input for implementing Sprint Planning). In the early stages when the product is still in the conceptual stage, Story Mapping helps the Product Owner build the product backlog at the most general level (including Epic & User Story items), before proceeding to detail the User Story . This task can be repeated before each new development stage, new function, or whenever the Product Owner feels the product backlog is gradually going to the original goal, scattered tasks, many disturbances, or Product roadmaps need to change to adapt to market changes.
5. Steps to build Story Mapping
a. Define goals of product / function
The Story Mapping session begins with the Product Owner sharing the goals of the new product / function. The product owner can use these 3 questions to suggest:
- What : what is the product trying to solve for the user? What product owner wants to develop, or what function does it want to develop?
- Who : Who is the user object of this new product / function? Benefits that the product / function gives users?
- Why : why should an organization consider developing this product / function?
b. Frame building (story backbone)
Story backbone is a list of functions / activities that need to be developed to achieve the goals set out in step 1. Backbone is built in general, not detailed. The product owner can build the backbone in two ways:
- Ask an expert (domain expert) to share about the business, the user object, the workflow needed, the problems users encounter & the common solutions. The shares are written on a memo & arranged in order of action
- Brainstorm with all members: in addition to the experts, members of the development team can also propose story backbone based on personal experience. The Product Owner gathers everyone’s suggestions, eliminates duplicates, & sorts in the order in which they are taken.
For example, with the goal of “building product search by catalog tree”, the story backbone may include the following:
- Choose a category
- Display the product list according to the selected category
- Select product & show product detail page
c. Identify & classify activities
In the list of activities listed in the story backbone, there are activities that can be grouped together according to user workflow, which work together towards a common goal, and others that are completely independent of each other. .
Independent operations, which can be performed at different stages in a vertical line. Activities that reside in a user workflow should be performed in a certain order, in a horizontal order.
For example, the Purchase & Account Registration function are 2 independent activities
- Purchase function: including product search activities -> see details -> add to cart -> make payment
- Seller account registration function: including activities Fill registration form -> Admin receives notification of new registration -> Admin approves registration form -> Seller receives notification of registration approval
d. Split the task (task -> subtask)
In the illustration below, the top horizontal row is the activities arranged in order when the user performs the checkout action (search for products -> see details -> add to cart -> perform bar maths). In each of these actions, there are sub-actions, more detailed to describe the major activity (e.g., making payments including entering card information, receiving information & order confirmation).
Some suggestions to help brainstorm break down tasks:
- What types of users can interact with this function, with each type of functional user will be different
- Unhappy path of the function will include which cases, how to handle
- In addition to the happy path, can the user make any unusual flow (for example, stopping the workflow before completion, changes made by other users affect the ability to complete the workflow)
- Consider other factors: UI, data, non-functional requirements (NFRs)
e. Review & find a missing point
The product owner should invite a UX designer or an expert with a different perspective to review the Story Mapping after construction. These members can identify gaps in the current Story Mapping & help the development team build Mapping in more detail.
f. Sort task & sub task priority
The Product Owner categorizes tasks into “Must”, “Should”, “Could”. High priority tasks are put first, low priority tasks go backward.
g. Create release plan
Based on the results of the prioritization, the Product Owner builds the release plan & identifies the required functions in each release. The development team is based on this result, estimating workloads and analyzing each task in more detail during sprint planning sessions
Source