Story Map
Information Radiators are one of the most powerful concepts championed in agile as communication vehicles. In many organizations, the use of information radiators has waxed over the past few years as more and more tools have locked data into monitors and tablet screens. As electronic tools have replaced paper, putting radiators where people can see information, as they work or walk by, has been replaced by instant access (which is code for never looked at). Product and sprint backlogs locked away into tools have the same problem as burndown charts, cycle time scatterplots or work in process aging charts that are in a tool and never looked at. Instead of locking backlogs away, create and use agile story maps to increase transparency and improve access to information. The goal of a Story Map is to present the big picture of a product or feature for everyone on the team. The Story Map’s ease-of-use and transparency increase the likelihood of collaboration and feedback within the team. The Story Map is also a tool to visually plan releases. Like other information radiators, the use of story maps has changed over over the last decade as the use of agile has become more mainstream and less tied to the principles in the Agile Manifesto. Over the next few entries, the Software Process and Measurement blog will revisit story mapping and explore several usage issues in today’s software development world. Before we dive into the hard parts, though, we need to revisit creating a story map.
Story mapping is a relatively simple process for visualizing and organizing a product backlog (the hard part is generally getting the initial set of features and stories). Story mapping was identified and popularized by Jeff Patton. The story map is a multidimensional representation of a product (we will talk later in this series about whether story maps work if you are not working on a product). Looking at a map from top to bottom, large items—epics or features—are placed at the top of the map. TIme or the user’s journey through the product is used to arrange the epics or features from left to right. For example, some of the features in a users journey for a product to sell books might include book search, book page, shopping cart, and shipping. This is sometimes known as a walking skeleton.
After the features have been arranged across the top of the map, user stories and enablers are arranged below the feature in “priority” order. Priority can be influenced by value or the order in which product owners and product managers want the software delivered (minimum viable product and/or release planning). For example, the epic “buy a book” might include a feature “shipping” which might include stories such as “search for shipping methods”, “display estimated shipping cost”, and ‘select shipping method’.
In July 2013 we described a simple process for capturing epics and building a story map. Story maps are a simple visual representation of work. Real life adds significant complications to the mix, such as distributed teams and work that is less product or feature-oriented. Deciding the right scenarios to use story maps should be part of every agile team’s workflow.
Like this:
Like Loading...
