Story Mapping
Story mapping is a useful approach when strategic choices are needed in a Product Backlog or similar, and works by providing a highly visible grid like representation of the product features and their decomposition into items such as User Stories.
The approach helps Product Owners to make good decisions with respect to the feedback about which combination of features or options of features will provide the best outcome and the greatest impact within the time and cost available.
Building a Story Map
Activities, Details, Backbones and Ribs
Start by telling a high level story of how the different groups of people will interact with the end product. Note them down with a few words on cards and sticky notes and begin to place them on the floor or on the wall in order, and these become the activities or backbone of the story map that show a user journey of how the end product is intended to be used.
(User stories were always intended to be conversation reminders rather than an exhaustive replacement for requirements. The name user story is to remind us about how they are used, not how they are written.)
As you continue the narrative to elaborate the story further, there may be higher level activities in the map as a higher level of abstraction that can take the form of headers or diagrams etc. to show the parent context, or lower level details to the story that form the detailed steps needed to achieve the activities, which begin to emerge. The "laddering up" and "laddering down" approach as the conversation continues can be useful to begin to fill out the story map with the activities or "backbone" arranged horizontally, and elaborating the detailed steps to achieve them, arranged vertically to form the "ribs".
Outcomes
The outcomes of a story map can be either a workflow, user experience journey or a system interaction for example. A story map can be enhanced with diagrams as the backbone of the story map to show the high level interactions either as a workflow, user experience or an architecture or system diagram for example that provides a wider context and allows the team to orientate themselves and the work for the initiative.
Other elements that may be useful are cards representing the goals of the project or initiative, the groups of people who might interact with the end product and cards describing any guiding principles or ideas for the work.
Good story maps use diagrams and drawings and allow some creativity to creep into the work. I once worked with a team that used a series of photos to indicate the user story's meaning and intention.
Slice for Releases
Once a story map has enough information on it to roughly describe the intentions then try to slice it horizontally into iterative releases or milestones. A good way to do this is to use tape or ribbon as a horizontal line through the story map with items above the line in the current release, and those below the line in the next release. Additionally, goals for the release can be placed at one side of the story map to give a reference for the horizontal release slice.
Items that may not make it to the releases can be placed under the release slices.
Slice for Learning
In addition to releases, it is also good to think about how to add horizontal slices in the story map for learning to provide answers to questions, neutralise risk or determine the way forwards. These slices are more strategic in nature when compared to the progress of releases, but can really help to influence the success of a project or product.
Tracer Bullet or Steel Thread
Arranging the very first release in a way to provide a very quick and basic end to end prototype can provide more insights into how things are going to work overall. These early releases are termed as "steel threads" or "tracer bullets" that form a backbone for the product that can then be built upon with successive releases. (Typically steel threads have the absolute minimum to provide the end to end connectivity, which may be simple request response interactions just to prove that a connection has been made ok.) This can be very useful too neutralise integration risk right from the start if there are a number of interconnecting systems and dependencies, or if early user feedback is needed to provide a basic prototype to understand if the concept is going to work or not.
The learning obtained from these quick prototypes can be invaluable at the start of a project and can positively influence the remainder of the work to be done whilst there is still time.
Iterative or Incremental
A release strategy can take the default approach of incrementally delivering features or user stories in a sequential order. An alternative is to take an iterative approach to deliver the rough first cut of the product, and then deliver subsequently improving iterations thereafter. The latter approach has the benefit of feedback early and often and is great to figure out how the product is going to work or hang together. The incremental approach is also good for small things that are well known, and so a composite strategy of incorporating horizontal iterations across the story map with vertical increments of known items that can be just dropped into a release can provide a dynamic and evolving strategy for the product delivery.
This approach can be great for uncovering the unknowns in a project and allow feedback and adjustment to be made.
Slice for Delivery
Once the story map has been sliced for releases with a learning approach applied, there should be a number of items that are not being worked on and a number of items still left in the release. Now is the time to now break these items down into the Minimum Viable Product (MVP) to form the absolute minimum to provide a product that is still viable. The intention here is to deliver something quickly to market with less work in order to gain some customer feedback or enable a revenue stream to pay for future features for example. Horizontal slices may now indicate goals, initiatives or iterations within the releases, and begins to form a detailed release plan or delivery road map.
Tags
A good idea is to tag stories or items with sticky notes, stickers, or coloured marks so that they can be easily categorised in a highly visible way that shows at a glance which items share the same tags. Tags can also be used to add temporary information, notes or questions for example.
Dots, coloured marks, stickers and coloured cards can be used to indicate different tags of things such as sub contexts, dependencies, exciters, "cheap" items, "expensive" options, needs more UX, gnarly brain problem or done items for example. Let your imagination go free.
Maintenance
When working with story maps it is a good idea to copy the cards from the story map and place them on team boards rather than take the story map card itself. This preserves the integrity of the story map and can be helpful if stories that are in the current iteration are tagged as "in progress".
When cards are done, simply tag them as done in a visible way on the story map rather than to remove them from the map, as this will show which work is done and provides a sense of progress.
Encouraging the product owner to constantly adjust and curate the story map is a good idea, as the story map is kept fresh and helps to stimulate further thoughts about the product from the product owner, rather than being a static list of cards that eventually fall off the wall. A little and often adjustment by the product owner is very useful to keep the story map alive and relevant.
See Also
- Sprint Planning & Product Backlog Refinement
- Product Backlog Refinement
- Backlog Strategy
- Backlog Strategy Archetypes
- Product Owner
References
- User Story Mapping, Patton J, 2014