Story mapping is a lightweight and collaborative approach to
defining and structuring user requirements. Story mapping involves describing
the system as a list of features that provide a sequential story of
requirements in a user-centric way. It supports iterative delivery where the
story is divided into Features which can be prioritized and grouped by planned
Releases/Minimum Marketable Features.
Approach
To come up
with a Story Map, start out by identifying user personas or the major
categories of users that gain value from the system. Next, identify the
business/user goals or the major objectives that the system must support. For
each goal, determine the user activities or the sequential events that the user
needs to do in order to get value. Finally, break the activities down into
explicit system Features that have real tangible business value.
Once the
overall narrative of the system is understood, the Story Map can be used to
prioritize the Features. For each of the activities, vertical component can be
added to define the priority of the features with respect to each other. Each
set of Features for a particular user activity are reshuffled and stacked
vertically according to their relative priority. The top row of the Features on
the story map represent the backbone of the product, which is the Minimum
Marketable Features (MMFs) that are required in order to have a functional
product. Features that may be delivered later (or sometimes never) are placed
lower down.
Once overall
prioritization of Features necessary to support each user activity is
understood, the entire Story Map can be divided by planned Releases/Minimum
Marketable Features. Horizontal lanes can be used to divide different MMFs from
each other. The Story Map can then be used to tell a narrative for a particular
MMF. This is done by traversing the map from left to right and only looking at
the Features within a particular lane.
Story
Mapping enables both a top-down and bottom-up perspective of the system to
emerge. It facilitates understanding of the system from the users' perspective.
It also lends itself to iterative delivery in that prioritization and grouping
of Features into Releases/Minimum Marketable Features is supported.
Nice article! I'm posting a link to in my upcoming monthly newsletter: .
ReplyDeleteAnd, by the way, "Requirements" is mis-spelled in the title. :)
Thanks for sharing Emad
ReplyDeleteThis an excellent start and nice way to reduce big requirements upfront while still considering the user goals in the development process. Helps to ensure both business and customer value is being delivered. I'll have to try and benefit my next project with a similar approach.
@J_WebSolutions
Thanks for keeping it simple, but I think the problem for any project of any magnitude is dependencies. If I have to say build something that requires two services, a UI widget and one service requires a new API, and I repeat this 50 times with any number of permutations and patterns, dependencies become very, very important. Both a simple backlog and a story map fall short. How do you recommend capturing the PERT nature of large-scale work?
ReplyDeleteThanks,
Jason