What is Story Map?
(More about the Story Map Feature) (Watch Live Demos)
Story Maps were first introduced by Jeff Patton in this 2005 article. The main idea behind Story Maps is that single-list product backlogs are a terrible way to organize and prioritize the work that needs to be done. A richer structure is necessary. A user story map is a powerful tool that enable an agile team to groom their product backlog and plan the product releases more effectively.
The story map captures the journey a customer takes with the product including activities and tasks they to perform with the system. Creating the story map collaboratively ensures team members are on the same page from the start of the project through to ongoing development of new releases.
Structure of Story Map
Story mapping is a top-down approach of requirement gathering and is represented as a tree. Story mapping starts from an user activities. A user activity should achieved a particular goals. And to complete an activity, users needs to perform the associated tasks. And these tasks can be transformed into epics and user stories for software development.
Visual Paradigm Story Map consists of 3 or 4 levels for dealing with different complexity of projects:
- 3 Level Story Map: User Activates > User Tasks > User Stories
- 4 Level Story Map: User Activates > User Tasks > Epics > User Stories
User Activities – They are laid out in the second column. This are major objectives that the system must support, with tangible business outcome. The entire row forms the backbone.
User Tasks – Each of the user activities is broke down into a set of related user tasks called narrative flow. The entire row forms the walking skeleton)
Epic / user stories – Each of the user tasks is broken down into Epics / User Stories underneath directly the user task that the feature realizes. Depending on the complexity of your projects, your team may choose the 3 or 4 level of story map which is more appropriate to you as mentioned above.
Release Plan
Use a separator to identify slices of tasks that users might use your software for to reach their goals. The smallest number of tasks that allow your specific target users to reach their goal compose a viable product release as shown in the Figure below: