One of the key objectives of a project inception is to collect requirements collaboratively. But, many times, it is difficult to decide where to start and what to focus on. Story mapping is an engaging activity where all participants are involved in the process of building the product backlog on a wall, versus writing a dull 100-page requirement document.
Story mapping is a top-down approach of requirement gathering and is represented as a tree. Story mapping starts from an overarching vision. A vision is achieved via goals. Goals are reached by completing activities. And to complete an activity, users needs to perform tasks. And these tasks can be transformed into user stories for software development.
Story Map Structure: Goals > Activities > Tasks > Stories
Lets take an example of an online store application’s one of the goal ‘Find product’ and build a branch of a story map to understand it better,
To achieve goal ‘Find product’ there are multiple ways such as ‘Browse through product category tree’, ‘Free text search’, ‘Promoted products’. Lets take one approach ‘Browse through product category tree’ to build our story map,
now to complete activity of reaching a required product, user needs to do perform certain tasks,
now this tasks can be converted to user stories for software development,
like this continue to deep dive each branch of the story map starting from goals and build the whole story map. In my experience building full story map takes from 3 days to 2 weeks based on project size and complexity.
For your reference, here is a sample branch of story map from real project,
and full story map after 5 days of activities looked like following,
Now we learned how to build story map, lets look at the advantages of it.
Sometime we need more information to be captured with story map e.g. nice to have stories, follow up questions, alternative approaches... This is like enriching the story map with more information. Following are few of the use cases of same,
In story mapping, defining a structure is important and then refine it as needed. The objective is to start with some structure in mind and evolve from it. Sometime it takes 2-3 iteration to get the structure right.
One alternative structure is based on ‘User Journeys’. User driven approach helps to identify requirements from user perspective e.g. buyer, seller, administrator etc. The map is then structured as User > Goals > User Journeys > Actions > Stories.
Another alternative, especially useful for NFRs (non-functional requirements) can use:
NFR > Requirement > Story.
Large projects may require up to 6 levels in a story map. However for smaller projects, 3 levels are usually sufficient.
Now that you are convinced about using story map for your next gig, lets look at what you need to get ready for the activity:
While doing story mapping I ran into challenges and found ways to overcome those. Following are tips to avoid those traps and help you run the story mapping successfully.
Story mapping is an effective inception tool to create a product backlog in a visually structured way. It helps in building a shared understanding, identify gaps in the backlog, see interdependencies, perform better relative sizing. Further, it can also help in slicing and release planning activities.
Many thanks to Gurpreet for review and valuable feedback.
If you have tried story mapping on your project, please share your learnings, thoughts, photos using comments.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.