Story Maps

Contents 1 Overview 2 Importance 3 PMI-ACP Exam Outline Reference 4 History 5 Disadvantages of a Traditional Backlog 6 Description of a Story Map 7 Current practice 8 See also 9 Sources & Reference 10 External Links

Community Guide of the PMI-ACP > Stakeholder Engagement

Please contribute to the community. Add content here

Overview

Story mapping is a technique popularized by Jeff Patton. Taking the backlogs a step further, 'it arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in the backlog and effectively plan holistic releases that delivery value to users and business with each release'.
Story-map tries to offer an alternative method than just following a prioritized backlog for project delivery. Instead of just delivering futures, it introduces a method where workflows are delivered, ensuring that every iteration , starting from the first one, will have as an output a viable product.

Importance

PMI-ACP Exam Outline Reference

History

The term was first coined by Jeff Patton in 2005 in his article It's All in How You Slice (Better Sofware, January 2005). In a later article of his he admits that it is not a novelty of his own as he had already seen similar models used by others. So he thinks to be more of a pattern rather than an innovation (4)

Disadvantages of a Traditional Backlog

The main problem of traditional Backlogs is that they are flat prioritized lists. Patton, in his article "It's All In How You Slice" (Better Software, January 2005) with which he introduced the idea of a Story-Map he describes the hypothetical situation where a project team delivers successfully the highest-value items in its backlog. However, the users cannot still get real value from the product because intermediate steps, of lower value, in their workflow are still missing.
Moreover, Arlen Bankston, mention the points below as areas were flat backlogs are not efficient: • Collaborative Building & Inspection • Seeing how everything fits together • Balancing a view of user-valued features with the need for iteration-size stories • Planning coherent value-based releases • Showing the big picture

Description of a Story Map

A story map describes a User Scenario in a more contextual way than the traditional backlog. Below we can see an example of a Story Map for a simple CRM system:

Following some of Patton's comments 'at the top of the map are “big stories” ('User Activities'). An activity is sort of a big thing that people do – something that has lot of steps, and don't always have a precise workflow. An activity is too big to put in an iteration or a sprint'. This level of detail is very much common with the more regularly used term 'epic' (which, however,as he says, he does not like to use). In other words, this series of User Activities is

This Story Map can be also seen as a two-dimensional table. In that table, the User Activities are placed along the x-axis, the axis of time. Here, by saying time we mean the sequence with which the User Activities are taken in order for the User Scenario to be completed. In other words, User Activities in time axis are the steps of a workflow.

Under the User Activities, task-centric stories are organized. The User-Stories are put under the relevant Activities. At the same time, user-stories that are of higher value are put higher in the y-axis of that table which represents its priority

The next step for the team is to plan the iterations and releases. In order to do that, the team is slicing the story map, along the workflow from its start till the end. This way it is ensured that a viable and useful product is delivered in each release, starting from the first one (Minimum Viable Product)

Teams are slicing this table to slices that always span from the start until the end of the x-axis, covering always the whole workflow. This way they deliver a viable and useful product from the first iteration.

The user story map contains two important anatomical features: The backbone of the application is the list of essential activities the application supports. The walking skeleton is the software that supports the least number of tasks across the full span of user experience

By slicing the map we can find ideal incremental releases. Choose coherent groups of features that consider the span of business functionality and user activities. Support all necessary activities with the first release (Minimum Viable Product). Improve activity support and add additional activities with subsequent releases. (6)

Current practice

See also

Sources & Reference

(1) Jeff Patton (2005), It's All in How You Slice, Better Software Magazine
(2) Kenneth S. Rubin, (2012), Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-Wesley Signature Series, pg. 96-98
(3) Alexander Maedche, Achim Botzenhardt, Ludwig Neer, (2012), Software for People: Fundamentals, Trends and Best Practices'', Springer, pg. 232

External Links

(4) [^http://www.agileproductdesign.com/blog/the_new_backlog.html]
(5) http://www.slideshare.net/VersionOne/story-mapping-in-a-nutshell
(6) http://www.agileproductdesign.com/downloads/patton_user_story_mapping.ppt
(7) http://www.agileproductdesign.com/presentations/user_story_mapping